Re: What's lacking: a good intermediate form

"cr88192" <cr88192@hotmail.com>
Tue, 3 Mar 2009 07:56:56 +1000

          From comp.compilers

Related articles
[9 earlier articles]
Re: What's lacking: a good intermediate form james.harris.1@googlemail.com (James Harris) (2009-02-27)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-28)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-28)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-28)
Re: What's lacking: a good intermediate form cr88192@hotmail.com (cr88192) (2009-03-01)
Re: What's lacking: a good intermediate form max@gustavus.edu (Max Hailperin) (2009-03-02)
Re: What's lacking: a good intermediate form cr88192@hotmail.com (cr88192) (2009-03-03)
Re: What's lacking: a good intermediate form james.harris.1@googlemail.com (James Harris) (2009-03-02)
Re: What's lacking: a good intermediate form walter@bytecraft.com (Walter Banks) (2009-03-03)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-03-03)
Re: What's lacking: a good intermediate form comp.lang.misc@inglorion.net (Robbert Haarman) (2009-03-04)
Re: What's lacking: a good intermediate form max@gustavus.edu (Max Hailperin) (2009-03-05)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-03-05)
[18 later articles]
| List of all articles for this month |

From: "cr88192" <cr88192@hotmail.com>
Newsgroups: comp.compilers
Date: Tue, 3 Mar 2009 07:56:56 +1000
Organization: albasani.net
References: 09-02-132 09-02-150 09-03-005
Keywords: UNCOL
Posted-Date: 03 Mar 2009 12:44:03 EST

"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, ...


Post a followup to this message

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