Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> On Thursday 01 April 2004 10:49, Leopold Toetsch wrote:
>>
>> I've a different roadmap:
>> 1) specify AST interface
>> 2) implement code generation from AST
> The PIR class is meant to be an (abstract) syntax tree.
> What kind of AST interface do you mean, a C API for bytecode generation?
A C API for AST generations with the code generators working from that.
> I think its best to different version, a PIR to Bytecode, a PIR to
> PASM and a PASM to Bytecode code genearator. They should IMO use the
> same interface to make them chainable if you want to.
Yes.
> PIR->PASM->Bytecode does not work at the moment, but there is IMO no
> technical reason not to support it.
The main problem is: PIR .sub/.end are distinct compilation units, while
a PASM file is processed as one big chunk. So e.g. local labels in
different subs with the same name collide. But it's true that it
wouldn't be too hard to spit out translated PASM code like so:
.emit
.pcc_sub _main:
...
.eom
.emit
.pcc_sub _func:
...
.eom
That's still a PIR file but with PASM contents.
>> 3) split PASM and PIR lexer/parser into 2 indpendent compilers
> The EBNF parser creates a class that has a method for each EBNF syntax-rule.
> The generated class is a lexer that will parse a Stream.
> EBNF's special-sequence will be used to call methods for successfully parsed
> syntax elements.
Ok. And that method can of course reside in the AST interface, maybe
wrapped with your proposed PBC class. There shouldn't be much difference
if the AST is built by your EBNF parser or by a yacc-like parser as in
YAL (s. http://toetsch.at/yal/).
>> 4) have a separate macro pre-processor run e.g. from an IO layer
> That is why I began to write a "Stream" class.
Ok.
> jens
leo
