Re: What's lacking: a good intermediate form

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


> > Maybe the way to go is to > byte the bullet and generate assembly
>instructions and stop worrying > about it. Then all I'd need is a
>good book like the Ron Mak book was > back in it's day. (I haven't
>paged thru the latest Dragon edition, > but surely I'd be more able
>to assess what's there now than the last > time I looked at it in the
>bookstore). It would appear that the newer > texts are too enamoured
>with GC and exceptions rather than locking > down the most needed
>basics. OK, so my question really is...


>> On modern desktop hardware, would anyone even notice the reduction of
>> program performance because of the rather stark non-optimised back end
>> code generation? (My guess is not, for 80% of software).
>
> Given you don't need to get max efficiency then yes, naive assembler
> would be fine.


It does seem so overbearing though noting that I don't want to become a
student of backend compiler technology as I know it is very complex (much
moreso than frontend work) and not a stepping stone of any sort for my
goals. A bit "too close to the hardware" for my liking. I'm thinking that it
is not feasible to implement anything useful with just mild knowledge and
effort on the backend. I'd opt for just pieces of stuff I need that C or C++
can't already do for me. Most of what I need is already in C/C++. I think
(but don't know) that using C or C++ as an IL is less than desirable though.
I don't mind passing-through directly the things that work in those
languages as I want them to (at least initially). At some time though, I'd
want a direct comparison of a full implementation of my language vs. C and
C++ and probably D, so the itch is always there to do a full-blown
implementation. That would be a milestone/assessment juncture.


>
>> (I read the documentation on C-- and think it would be better to have
>> an assembly language toolkit for major processors with the commonly
>> generated code wrapped in C functions: setting up a stack, etc.)
>
> Interesting. I haven't looked at C-- for a long time but again you are
> probably right that an assembly language toolkit would be better
> (because it can be used more flexibly) as long as you don't have to
> target many architectures. Such a toolkit would certainly be more
> adaptable. The basic meaning of "compiler" is to, er, compile the
> program from pieces of code. You could start that way and improve
> efficiency as needed.


There used to be something called "Assembly Language Toolkit" (a
commercial product). A quick google on that though doesn't find it. I
remember it from the late '80's. It was a library of assembly routines
callable from C. It may have even been inline assembly, I never used
it. Something like it though for compiler implementers seems
lucrative. I mean, how many ways are there to set up a call stack on
x86? And why would I want to bother with that as a language designer?


Tony
[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]

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