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

  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).