Hi,
On Thursday 01 April 2004 10:49, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > Hi all!
> >
> > I propose the following because the current IMCC reimplementation seems
> > to make no progress.
>
> 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?
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.
PIR->PASM->Bytecode does not work at the moment, but there is IMO no technical
reason not to support it.
> 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.
An EBNF Syntax for preprocessed PIR code does look somehow like:
parameter = string parameter | integer parameter;
string parameter = first quote parameter | second quote parameter;
first quote parameter = "'", {character - "'"}, "'";
second quote parameter = '"', {character - '"'}, '"';
integer parameter = digits;
opcode letter = downcase letter;
opcode name = opcode letter, { opcode letter, '_'}, opcode letter;
(* call method "instr" for each instruction, *)
(* with a hash containing a key "op" and "para" *)
instruction = (opcode name ?store:op?, spaces, parameter ?store:para?,
{{space}, ",", {space}, parameter}) ?call:instr?;
comment = '#', character - (newline), newline;
source line = {space}, [instruction], {space}, [comment];
source = {source line, newline}, [source line];
The lexer code will be generated automatically from this.
> 4) have a separate macro pre-processor run e.g. from an IO layer
That is why I began to write a "Stream" class.
A Stream can either be a Parrot IO, a Filter applying to another stream, a
Coroutine or whatnot.
Seeking in a stream would not be possible by design - if you have to go back
inside the stream at some point, you can clone the stream which will
introduce a buffer behind the scene that is used to replay the stream.
> 5) change both PASM/PIR compiler to use the AST interface
>
> > ## first part ##
> > Create a (bytecode) class "PIR" that can be used (by compilers written in
> > bytecode) as an standardized interface to IMCC.
>
> You can already run arbitrary compilers with the C<compreg> interface,
> when your compiler spits out sourcecode. And it's rather simple to have a
> compiler written in C (s. examples/compilers/japhc.c). Missing is just
> some general API but that will be done along with 1).
Yes, but what about compilers that are emitting an AST? AST transforming
should be faster than parsing generated sourcecode.
> > ## second part ##
> > Write a PIR lexer/parser in a language targeting parrot
>
> W/o some kind of regex support that's a PITA.
See the EBNF example above.
> leo
jens
