Re: What's lacking: a good intermediate form

"George Peter Staplin" <georgeps@xmission.com> wrote in message
> 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.


(I was probably thinking about some kind of data structure IR rather
than a language or bytecode when I originally posted. I have read that
microsoft is going to offer (maybe already does in beta VS?) APIs to
it's AST, which could be just what the doctor ordered).


I wasn't suggesting that portability was a necessary feature of the
intermediate representation. I just want it to be easy to experiment
with language design on my x86 machine without having to write a
compiler backend which seems like something the hardware manufacturer
should provide (if that is, of course, possible). If an x86-LIKE
processor vendor had something like that to offer, I would buy it
instead of it's competitor's product that didn't offer that (hint,
hint). An IR would have to have backends available to be of any use to
me.


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


Simplistically, to me, it seems like that goal was too broad. CISC and RISC
are different beasts. (Yes, I know that modern processors are mostly both
and not in those distinct camps anymore, but I'm sure there is much validity
in the thought still).


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


As an aspiring language designer/developer (and one running out of time), I
just need a product on the machine I currently have to avoid having to write
a compiler backend. I can get through doing the frontend stuff (I think).
Heck, I might even opt for a frontend tool too probably because my goal is
the language and not the implementation (though I want the language to be
easy to implement, so writing the frontend seems a given stepping stone).
Currently my goal is to avoid lex/yac -like tools so as not to lose sight of
the language's implementation complexity.


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


The introduction of the documentation is easy to grok too. But it was
written in 1983! The simplifying assumptions made back then may not be
plausible anymore. The outer-scope question is still though WHAT the IR
should be: maybe bytecode, maybe an AST, maybe... ? It would seem that just
an AST is not enough for something has to decipher it's meaning. Or not! I
dunno! An AST that is closer to the backend rather than just a frontend data
structure? That's probably what I am looking for: some defined form to parse
my language's syntax into, push a button and output is the .exe. :) That
indeed may be MS's AST (too bad it's proprietary). They maybe already have
what I want and they use it to implement all the languages that plug into
Visual Studio? I'm going to the web and see what I can find on MS's AST.
(Developing such a thing, a general AST seems like something not outside of
my realm of capability/desire, not for this week (yr?) though!).


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


I've successfully avoid learning assembly this long, I sure would like to
keep it that way (though I do pick up tidbits of it here and there and am
not oblivious to it).


Tony

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