Ken Raeburn <[EMAIL PROTECTED]> wrote:
Sorry if this is continuing to drift off-topic, but... the macro form
Richard proposes:
#define temp_STATUS (*(char *)0x23)
wouldn't give any useful information to the debugger in the toolchains
I've used (mostly gcc and other unix compilers), where the debug
information is based on post-cpp text. Putting the variable into the
symbol table also lets the compiler and linker both check for things
like multiple variables declared at the same address, overlapping
variables, etc. And as long as the "@ ADDR" notation is seen in each
compilation unit, the compiler can still do its optimization work.
Er, in the extremely limited amount of programming I've done or inspected
at that level, it was sometimes _necessary_ to put more than one variable
at the same address, and you couldn't hack that in the usual way by putting
the fields in a union, because you couldn't trust the compilers to align
unions the same way they would align "bare" variables.
Note that the kinds of applications where this is needed are not supported
by gcc or gdb, and while remote debugging is a theoretical possibility, the
"stub" you'd need in the processor would probably be as large as or larger
than the code you want to debug. You'd need to use some kind of emulator.
The very simplest approach is simply to put 'extern' declarations in a
header, and put the absolute address bindings in a little bit of assembler.
And yes, you can use something like M4 for that too, producing both the
C extern declarations and the .s file from the same source.
There's also a perfectly standard mechanism that could have been used without
any bending of C syntax. Instead of
int foo @ 23;
write
#pragma place(foo,23)
int foo;
That's the kind of thing pragmas are _for_.
Steering back towards being on-topic, I think Lionel Fourquaux has an
interesting idea, a way to define additional properties and how they
should be handled.
I've already shown one way that different source code can be presented to
the embedded-C compiler and the LC-lint checker, using M4.
Pragmas are an ideal way to attach properties to identifiers.
Defining new macros should be trivial. Defining new integral types,
slightly more complicated. New grammar constructs could *probably* be
done without too much pain, if they don't require parsing arbitrary
expressions. For example, you could drop something in between
tokenizing and parsing that recognizes "@" and looks for a following
integer constant, or "__attribute__" and parens and so forth,
returning to the parser a "magic extension" token with the relevant
data attached. The parser could accept these tokens at certain points
in the grammar, and do something simple like "apply this extension
data to this variable decl", which would have to call back to the
extension code.
Read the chapter on 'app' (annotating C preprocessor) in the book
on Practical Reusable UNIX Software, or whatever it's called. AT&T have
already faced this problem and published a solution.
