On 10/13/06, Sean Walton <[EMAIL PROTECTED]> wrote:
David Gay wrote:
> 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++?
The code is based on gcc which is written in C. I'm not a particularly
big fan of C++ (that discussion is way too long to have here ;-)).
2) Use lisp as a structure builder, et al.? (I did a cursory review
of the gcc 4.x.x and found no precedent)
Something has to build the code from the spec (.def file). Why not use
emacs lisp? (it is widely available, unlike most other versions of
lisp)
3) Use regions when (while they are interesting) they are currently
not widely accepted?
I wrote the C frontend nesC is based on for my thesis (look it up, and
you'll understand). Regions are a perfectly good programming tool for
some problems (note that they are used in gcc under the name obstacks,
in lcc (another C compiler), in Apache, etc). They are nice for
problems where object lifetimes correlate well with the code
structure.
4) Re-engineer "attributes" when they appear to be a standard
feature in gcc?
nesC is not supposed to be gcc-specific. gcc attributes are not user
extensible. And, frankly, the gcc attribute syntax sucks in many ways.
You might also note that the attributes are not exactly
"reengineered", but derived from Java 1.5's attributes.
On AOP: you might want to note that configurations/wiring allow
interposing behaviour on function calls...
David Gay
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
