"Rod Pemberton" <do_not_have@[EMAIL PROTECTED]
> wrote in message
news:fpp1at$dd7$1@[EMAIL PROTECTED]
> "cr88192" <cr88192@[EMAIL PROTECTED]
> wrote in message
> news:c05b0$47bfeebb$ca83b482$9782@[EMAIL PROTECTED]
>> 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
> like
>> this:
>> Preprocessor;
>> Parser;
>> Upper Compiler, converts syntax trees to RPNIL;
>> Lower Compiler, converts RPNIL to assembler;
>> Assembler;
>> Linker.
>>
> [wants/needs restructuring...., but very far along in project]
>> anyone have any thoughts?...
>>
>
> Obviously, only you really know your code and the complexities of
changing
> it... But, at this point, I'd think you'd want to preserve RPNIL and
> perhaps even concentrate it. Then, add SSA to allow you to select
between
> the two or gradually migrate away from RPNIL.
>
ok.
> First, I think you should rework the compiler so that the upper compiler
> _only_ "converts syntax trees to RPNIL."
this is what it mostly does (none of the logic from the lower compiler
exists in the upper compiler, and the only real communication between them
is spewing everything into a buffer and passing it along).
originally, I had intended it to do more, making the compiler more
retargetable by easily swapping out the lower end of the compiler, but the
lower end ended up being large and complicated enough that it is no longer
reasonable...
> Second, migrate the upper compiler's "easy-lifting" i.e., "basic
> types-related processing, constant folding, some branch elimination",
into
> the "heavy-lifting" area of the lower compiler as RPNIL.
not terribly reasonable, as a certain amount has to be done in the upper
compiler just to make the language hold together (C and similar are
annoying
in this way).
some of the constructions (such as destructuring 'if' statements and
loops,
can't really be sent much lower, since these will not map nicely to RPN
anyways...).
if/when I implement C++ or similar, likely a bit more will need to happen
in
said upper compiler...
> Third, now that all processing is done in RPNIL, insert an SSA
processing
> layer between the "heavy-lifting" area in RPNIL and the RPNIL to
assembly.
>
> I.e.,
>
> (purified) Upper Compiler, *only* converts syntax trees to RPNIL
> (modified, split) Lower Compiler part A, "heavy-lifting and merged
upper
> compiler easy-lifting" in RPNIL
> (new) convert RPNIL to SSA
> (new) perform SSA only transforms
> (new) convert SSA to RPNIL
> (kept, split) Lower Compiler part B, converts RPNIL to assembler
>
I am not sure what point there would be in going twice through RPNIL,
since
it is high level enough that going back to it would probably eliminate
most
of what could be done by going through SSA (RPNIL is at a similar level of
abstraction to the likes of MSIL/CIL, only that the compiler recieves
textual input rather than bytecode).
RPNIL was originally intended as a "general purpose" output for compilers
anyways, me reasoning that RPN was a good solid model, and easy to target
(I
figured SSA would be much harder to target since one needs to keep track
of
names and similar).
2 3 + 4 *
vs:
mov.i r0 2
mov.i r1 3
add r2 r0 r1
mov.i r3 4
mul r4 r2 r3
so, yeah, RPN has a clear advantage in this respect...
> Now that you have both layers, if you want to gradually eliminate RPNIL,
> you
> can. Or, you have your choice of which is better.
>
probably, it will go like this:
Syntax Trees (currently implemented as XML DOM trees) to RPNIL;
RPNIL to SSA;
further SSA based processing;
SSA to ASM.
as such, I could probably loosen up the SSA handling, making SSA be the
intermediate representation between these stages. then the question would
be
one of using a textual or binary representation between stages (I am more
inclined towards textual...)
probable syntax:
likely line-oriented, and based on the "<opr> <args*>" layout (very easy
to
parse);
types will be sticky, so registers will remember what they are (vs
endlessly
having to restate them);
any conversions will need to be explicit, and operator types will need to
agree;
....
most forms with a target will look like:
<opr> <dest> <args*>
for example:
mul r2 r0 r1 //r2=r0*r1
>
> Rod Pemberton
>
|
