David Gay wrote:
On 10/11/06, Sean Walton <[EMAIL PROTECTED]> wrote:
I have been working on extending the nesC compiler. I have been
stepping through and watching the compiler load the different support
files. Looking through the data structures, I can't find the source's
data objects. It appears that the algorithm looks like this but I can't
find the data structures to support it:
Load named file
If not found locally, look for it in provided path
Get list of associated files
Load named file
I'm assuming that CPP is called to preprocess the directives...
Where in the compiler source is the file fully loaded? And, could
anyone describe for me what the AST data structures look like
(especially those structures that can't be discerned from gdb)?
The types are defined in AST_defs.h, from the definition in a file
called nodetypes.def (a bunch of AST* files are generated from that
file). I'm confused about the gdb comment - there are no structures
"that can't be discerned from gdb", assuming you compiled with
debugging on. nodetypes.def defines an "object-oriented" AST, where
the kind field tells you the type of the current AST node (so the
static C type may sometimes be a "supertype" of the actual AST node
type - if the kind is kind_foo, then you can cast a pointer to the
object to a foo*).
Note that I do not have the time available to any deep level of
handholding. The structure of the nesC compiler isn't particularly
different from any other compiler out there (in fact it's basically
derived from gcc's front end). The nesC specific bits are basically
about:
- loading the components and interfaces specified by other components
(this is a recursive process)
- dealing with the wiring specified by the configurations
- instantiating generic components (this gets tricky)
and then outputing all that as one big C file.
David Gay
David, please take this in the spirit that it's intended: I honestly
want to know why you chose to implement this the way you did. Why did you:
1) Simulate inheritance instead of using C++?
2) Use lisp as a structure builder, et al.? (I did a cursory review
of the gcc 4.x.x and found no precedent)
3) Use regions when (while they are interesting) they are currently
not widely accepted?
4) Re-engineer "attributes" when they appear to be a standard
feature in gcc?
Let me tell you what I am doing (or attempting to do). I would like to
extend nesC with aspect oriented programming (AOP). The nesC language
provides a unique "playground" for trying out new AOP techniques. I
envision that the best place to run the AOP rule filters ("pointcuts"
and "advice") would be _after_ loading and building the AST and before
any transformations (like wirings, instantiations).
Understanding the basis of this design will help me tremendously.
-Sean Walton
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
