In my wanders through the parrot/languages subdirectories, it appears that
most example languages implement a complete compiler (ie lexxer -> parser
-> optimizer -> code emitter), which seems to be somewhat of a
duplication of labour. Has or is anyone worked on a framework a la gcc
which would only require that new languages have a lexxer/parser written
that coerced data into a standardized AST which could be passed off to other
compilation stages? (Similarly, other end targets (such as Java bytecode
or native code would only require the implementation of a new code
emission module.)
-c
Tanton
Some are in C, others in pasm and yet others in Perl ... how do do you re-use
libraries in that case ? ...
> Has or is anyone worked on a framework a la gcc
gcc is not my ideal pick because it has an RTL bridge in between ... But I
get the idea ...
> which would only require that new languages have a lexxer/parser written
> that coerced data into a standardized AST which could be passed off to other
> compilation stages? (Similarly, other end targets (such as Java bytecode
> or native code would only require the implementation of a new code
> emission module.)
I have been working on just such a compiler collection , which generates
.NET IL & JVM from C# ... The next target is obviously Parrot and we plan
at acheiving this by adding a new PMCodegen to the compiler backend.
It uses a custom AST management tool (TreeCC) which should speed up
development of ASTs. The system combines visitors and inhertiance to
simplify compiler dev.
Anyway treecc is there if you want to simplify AST management ... though
I should say it's a bit different from OO or procedural programming ,it's
aspect oriented... takes some getting used to.
Take a look at the DotGNU portable.net's CSCC for examples, if you want
to ... (and no, -mparrot will not work, though -mjvm might...)
Gopal
--
The difference between insanity and genius is measured by success
"Tanton Gibbs" <thg...@deltafarms.com>
01/18/2003 01:10 AM
To: "Cory Spencer" <cspe...@sprocket.org>, <perl6-i...@perl.org>
cc:
Subject: Re: Parrot compilers
Yes, languages should now use IMCC as their target. Basically, they
generate IMCC instructions without regards for optimization and such so
that
only a lexer/parser is needed. Take a look at the bf and ook languages
for
an example. I think perl6 is also heading there.
Tanton
----- Original Message -----
From: "Cory Spencer" <cspe...@sprocket.org>
To: <perl6-i...@perl.org>
Sent: Friday, January 17, 2003 9:10 PM
Subject: Parrot compilers
>
> Hey folks -
>
> In my wanders through the parrot/languages subdirectories, it appears
that
> most example languages implement a complete compiler (ie lexxer ->
parser
> -> optimizer -> code emitter), which seems to be somewhat of a
> duplication of labour. Has or is anyone worked on a framework a la gcc
> which would only require that new languages have a lexxer/parser written
> that coerced data into a standardized AST which could be passed off to
other
> compilation stages? (Similarly, other end targets (such as Java
bytecode
> or native code would only require the implementation of a new code
> emission module.)
>
> -c
>
>
>
Regards.
--
Will "Coke" Coleda
IMCC, as many people have pointed out, is a step in this chain, as it
means now that you can go:
lexer->parser->simple code emitter->(parrot+imcc)
rather than
lexer->parser->code emitter->optimizer->parrot
IMCC doesn't completely remove the need to translate to parrot
assembly, or something reasonably equivalent, but that's the next
step.
The plan, such as it is, is to get the perl 6 regex spec implemented,
and then use it to handle the front end parts, the lexing and
parsing. IMCC will be beefed up to take in ASTs that the lexer/parser
emit, and then it should just be a matter of building the rules.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk