|compiler and metadata, request opinions... firstname.lastname@example.org (cr88192) (2009-04-22)|
|Re: compiler and metadata, request opinions... DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-24)|
|Re: compiler and metadata, request opinions... email@example.com (cr88192) (2009-04-25)|
|Re: compiler and metadata, request opinions... DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-04-27)|
|Re: compiler and metadata, request opinions... firstname.lastname@example.org (cr88192) (2009-04-28)|
|From:||Hans-Peter Diettrich <DrDiettrich1@aol.com>|
|Date:||Fri, 24 Apr 2009 20:31:08 +0200|
|Posted-Date:||25 Apr 2009 14:51:29 EDT|
> I am actually using the same parser for all 3 languages (and C++ as well,
> but this is a lower priority), where an internal "lang" variable is used to
> remember which language is being processed at the time (and adapt behavior
> as appropriate).
I'd use different frontends (parser...) for each language, each building
an canonical AST. Where "canonical" means that the AST is understood by
all following stages.
Problematic are e.g. classes, which have different implementations and
behaviour in C++, Java, .NET etc., so that the generated code for
dealing with an object has to take into account the language's class
model and lifetime rules.
> I have determined that, due to semantic and architectural issues, I can't
> embed the metadata directly into the object modules (the reason being that
> COFF and ELF modules are loaded as needed, but for technical reasons all of
> the metadata needs to be available to the runtime prior to the linking
What exactly is "metadata"?
> further context:
> portions of the runtime may register themselves with the linker, where a
> request for a particular piece of information is embedded in a symbol (sort
> of like in HTTP CGI requests), and so when a module is linked, the runtime
> may recieve the request and generate any code or data necessary to fullfill
> this request.
That's a consequent extension of the selectable frontend (language...).
The FreePascal compiler has an interesting model for dealing with
different target widgetsets, machines and systems. cpp will have a
similar model (dunno). You can declare abstract classes or interfaces
for your AST nodes and targets, and instantiate the appropriate
object(s) when the language, library type etc. is known.
Return to the
Search the comp.compilers archives again.