All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Georg Nikodym <georgn@somanetworks.com>
Cc: Pantelis Antoniou <panto@intracom.gr>,
	Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Standard way of generating assembler offsets
Date: Mon, 08 Oct 2001 12:00:38 -0700	[thread overview]
Message-ID: <3BC1F7D6.E84D617B@mvista.com> (raw)
In-Reply-To: <28136.1002196028@ocs3.intra.ocs.com.au> <3BC1735F.41CBF5C1@intracom.gr>  <3BC1E294.1A4FB12D@mvista.com> <1002563771.21079.3.camel@keller>

Georg Nikodym wrote:
> 
> At the risk of sticking my foot in it, is there something wrong with the
> ANSI C offsetof() macro, defined in <stddef.h>?
> 
> --Georg
No, and it could have been (and was) written prio to ANSI C defining
it.  Something like:

#define offsetof(x, instruct) &((struct instruct *)0)->x

The issues that CPP resolves have to deal with the following sort of
structure:

struct instruct {
	struct foo * bar;
#ifdef CONFIG_OPTION_DIDDLE
	int diddle_flag;
	int diddle_array[CONFIG_DIDDLE_SIZE];
#endif
	int x;
}

Or for the simple need for a constant:

#define Const (CONFIG_DIDDLE_SIZE * sizeof(int))

Of course you could have any number of constant operators in the
expression.  Note also, that the array in the structure above is defined
by a CONFIG symbol.  This could also involve math, i.e.:

#define CONFIG_DIDDLE_SIZE CLOCK_RATE / HZ

and so on.  All in all, it best to let CPP do what it does best and
scarf up the result:

#define GENERATE_CONSTANT(name,c) printf(#name " equ %d\n",c)

then:

GENERATE_CONSTANT(diddle_size,CONFIG_DIDDLE_SIZE);

In the code we did, we put all the GENERATE macros in a .h file.  The
the code looked like:

#include.... all the headers needed....

#include <generate.h>

GENERATE....  all the generate macro calls...

} // all done (assumes that the "main(){" is in the generate.h file)

This whole mess was included as comments in the asm file.  The make rule
then used a sed script to extract it, compile and run it to produce a
new header file which the asm source included outside of the above
stuff.

George

  reply	other threads:[~2001-10-08 19:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-04 11:47 [RFC] Standard way of generating assembler offsets Keith Owens
2001-10-04 15:36 ` george anzinger
2001-10-05  5:48   ` Keith Owens
2001-10-06  5:21 ` Keith Owens
2001-10-08  9:35 ` Pantelis Antoniou
2001-10-08  9:49   ` David S. Miller
2001-10-09  7:25     ` Pantelis Antoniou
2001-10-09  9:24       ` David S. Miller
2001-10-14 11:27     ` Keith Owens
2001-10-08 17:29   ` george anzinger
2001-10-08 17:56     ` Georg Nikodym
2001-10-08 19:00       ` george anzinger [this message]
2001-10-09  7:38         ` Pantelis Antoniou
2001-10-09  9:28           ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BC1F7D6.E84D617B@mvista.com \
    --to=george@mvista.com \
    --cc=georgn@somanetworks.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=panto@intracom.gr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.