LKML Archive on 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
next prev parent 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 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 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
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
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 \
--subject='Re: [RFC] Standard way of generating assembler offsets' \
/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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).