Re: What's lacking: a good intermediate form

Tony wrote:


> Or maybe I'm making the problem to hard (?). 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).
>
> (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.)
>
> Tony


I agree such a thing is lacking. LLVM is apparently good, but it
requires working with their own code generation language from what I
understand, or C++. I worked on my own libasm (not related to the
more popular libasm on the web) for MIPS, and x86 runtime machine code
generation. It's difficult to create an intermediate *portable*
format. Mine ended up looking like Forth almost, and then I tried to
port it to a Sparc, and failed, because my design wasn't ideal for the
Sparc constraints.


With regard to intermediate formats there have been many attempts, and
many are still in use, but none have taken the world by storm from
what I've seen. There are formats like ANDF from TENDRA, and IIRC the
Oberon system has some code generator that generates portable
executables on the fly, similar to a JIT engine, but without the
typical bytecode from what I recall.


I was looking at the Amsterdam Compiler Kit the other day. I could
use a simple machine code generator that works with an intermediate
form that is rather simple, and perhaps more portable too.


Regarding assembly language: it's not difficult to learn assembly
language. Learn the instructions/vocabulary and then find the
necessary context to interpret the vocabulary and piece together the
instructions. The problem is if you ever want to port that code to a
few other popular processors, or embedded systems, it becomes a
difficult task. The number of assembly language programmers is
relatively small, so it's difficult to find people to help port your
code too.


-George
[Oberon's system was called slim binaries, and apparently worked well
for a single strongly typed source language and a modest set of 32 bit
byte addressed targets. -John]

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