Re: issue: RPN, TAC+SSA, and x86-style ASM

On Feb 23, 4:08=A0am, "cr88192" <cr88...@[EMAIL PROTECTED]
> wrote:
> well, recently I came up with an idea, but it has turned into a bit of a
> mess on me...
>
> I have an existing C compiler I wrote before, and it is organized about
li=
ke
> this:
> Preprocessor;
> Parser;
> Upper Compiler, converts syntax trees to RPNIL;
> Lower Compiler, converts RPNIL to assembler;
> Assembler;
> Linker.
>
> so, the upper-compiler ends up being fairly sparse, mostly being a
fairly
> dumb converter.
>
> the output, I call RPNIL, is a vaguely Forth or PostScript like language
> representing the intermediate version of the language.
>
> some of the basic types-related processing, constant folding, some
branch
> elimination, ... has been done before any of this RPNIL code is
generated
> (likewise, the various high level constructions have been decomposed
into
> labels and conditional jumps).
>
> meanwhile, the lower-compiler does much of the "heavy lifting",
implementi=
ng
> many things I had not really originally intended (nearly the entire
types
> tower, operator overloading, inlining, ...), and goes all the way down
to
> machine code (when this compiler project was started, it was originally
> assumed that this lower end would be simple and stupid, but it ended up
> being one of the largest and complicated pieces of the project).


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.