Re: What's lacking: a good intermediate form

"Tony" <tony@my.net> wrote in message news:09-03-005@comp.compilers...
> "James Harris" <james.harris.1@googlemail.com> wrote in message
>> On 26 Feb, 03:46, "Tony" <t...@my.net> wrote:
>>> Or maybe I'm making the problem to hard (?).
>>
>> No, you are right. Trouble is, no one has defined an IR that suits
>> everyone.
>
> So one that becomes widely available may "win" just because there is
> nothing else out there. (Again, I'm thinking about MS's AST).
>


<snip>


> [Really, before you waste time trying to write yet another universal
> intermediate language, wouldn't it be a good idea to look at all of
> the attempts during the past 50 years and why they all failed? It's
> not because the people working on them were dumb. -John]


yeah, I think the usual problem is that it is problematic to find an IL that
is useful in all cases...


people may differ in terms of things like:
desired level of abstraction;
internal workings (some people just have a strong and hard desire for SSA,
...);
method of interface (tool, library, or textual vs function calls) and type
of input/output;
performance overhead (especially relevant to JIT and dynamic compilers);
code overhead (just how much code will this add to the project?...);
type of language this is suited for / built-in semantics;
...




even for ones' own uses, they may need to change the IL if their
requirements change enough.
for example, my old IL was RPN based, but I am in the process of beating
together a Lisp-like IL (it mostly borrows from Scheme, but many things it
does are not all that Scheme-like, and a not so small number of variations
from the standard...).


but, yes, several days in and I have most of a core interpreter + core
language features, but not so much yet in terms of bindings into the
compiler machinery...


even as yet, I still have doubts...


such as:
really, will it be all that much less effort to work with than good old RPN
and hard-coding all the machinery in C?
what of the effort of binding this language into the existing compiler
machinery?
...


sadly, I am not even sure as of yet how the code transformation should work,
for example, if this language will take up an executive role and drive
all/most of the code generation machinery, or if it would be better to use
this more as a translation phase (from the input to a form mostly resembling
an S-Exp version of the prior RPNIL language) and keep most of the executive
machinery in C.


another question is the level of abstraction of the input, for example, if I
should flatten loops prior to handling them here, or if they should be left
unflattened and this stage would do things like loop unrolling, ...

Return to the comp.compilers page.
Search the comp.compilers archives again.