<robertwessel2@[EMAIL PROTECTED]
> wrote in message
news:558037f6-299d-462b-9930-86e29c6f73f4@[EMAIL PROTECTED]
>
>
> The front-end/back-end split is usually such that there are no
> lexical, syntactic or semantic issues left for the back end to deal
> with. Almost universally it's considered a good idea to begin code
> generation with no ambiguities left in the source (obviously excluding
> anything that's defined to be ambiguous until runtime). If you've got
> a significant amount of that sort of stuff left in your back end, you
> may want to consider getting that moved up first.
>
there are no lexical or syntactic issues.
but, however, it does handle most of the semantics.
the reason is that I had started out with an abstract stack machine
(basically, vaguely PostScript style, where we have a stack and operations
that work on pretty much anything they are given), and during development,
ever more things were done as the codegen became more developed.
now, the thing is very complicated...
the idea is then to split this level up, so that the lower level deals
almost purely with architectural issues (register allocation and
operations,
....), and the RPNIL compiler becomes more the "middle end" rather than
the
"lower end".
so, the upper compiler:
does preprocessing and parsing;
does a some amount of AST level operations (folding constant expressions,
eliminating dead branches, ...);
converts ASTs into a more or less stack-based representation.
the 'RPNIL' compiler:
deals with said abstract stack-based computational model;
decomposes complex types and operations into basic architectural types
(raw
pointers, memory, and register operations);
also handles things like type conversions, function calls, the type tower,
operator overloading, and inlining;
....
the 'VRM' layer:
does things like register allocation, figures out good ways to perform
register/memory and memory/memory operations;
emits assembler.
assembler and so on: ...
partly all this is because, originally, my compiler mutated out of an
interpreter for a dynamically typed scripting language of mine.
as such, everything RPNIL or lower, was originally handled in what was
originally the interpreter or JIT compiler (the major change was that of
going over to using a textual representation rather than raw bytecode,
originally due to issues that would have been involved trying to hack the
two layers together at the bytecode level due to representational
differences, it was much easier just to dump the output into a textual
buffer and re-parse in terms of the RPNIL compiler's bytecode...).
the upper compiler was originally a severely hacked-over version of the
script language's upper compiler (and, thus, operates at a similar level
of
abstraction, which may not be perfectly well suited to a language like C,
but oh well...).
later on, this upper compiler was rewritten to use DOM trees instead of
S-Expressions (and be, in general, a little less hackish), but otherwise
does not do much differently than before.
or such...
|
