Re: What's lacking: a good intermediate form

"cr88192" <cr88192@hotmail.com> wrote in message
news:09-02-142@comp.compilers...
> "Tony" <tony@my.net> wrote in message news:09-02-132@comp.compilers...
>> 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).
>>
>
> probably not...
>
> actually, even with rather poor assembler, one can still get within 2x
> or 3x of decently good compiler output (AKA: gcc with default
> settings...).


I used to find this amusing: When I first wrote compilers in the 80's
(in my spare time) code efficiency was the last thing I was worried
about. Yet programs still ran faster than compiled C code.


A couple of tests I've just done with a 10-year-old compiler (with
little change on the code front) against gcc -O3 showed one program
twice as fast with gcc, but another 20% slower on gcc.


This wasn't bad considering how little effort I put into my compilers
and how much work and expertise goes into a mainstream compiler
(although I haven't tried Intel C compiler which is supposed to be
good).


(I make up the difference by having really nice inline assembler in my
language...)


> early on this was actually an encouragement:
> I was able to more or less match gcc's performance on some tasks with a
> crude JIT, which basically converted a good number of specialized
> bytecodes for a language of mine into machine code.
>
> of course, this sent me head-first into compiler writing (me thinking,
> "well, it can't be too much more work to compile C...", but I was wrong...
> an interpreter, assembler, and straightforward JIT are easy, but a full
> fledged compiler is a PAIN...). sadly, it is sort of like with geometry or
> physics code, namely that the code is not large, but it is a pain to write
> and work on...


> so, from starting out, it took about 6 months before I was compiling
> C code with it, and 1.5 years later, it is not doing a whole lot
> more (no working C# or Java frontends, or even a complete x86-64
> backend, ...). it is like a huge effort sink...


It used to take me 2-3 months to create a compiler, just to get it
working enough to use it for my real work. Probably half the features
I'd put in the language got left out. (This was not for C language
which I think helped a lot, although my language did the same sorts of
things.)


On the other hand, I've been tinkering on and off for years now on a
new language/compiler project which is going nowhere at present. But I
just think of it as alternative therapy to Sudoku.


> basically, my compiler is more or less split into an upper-compiler,
> a middle-compiler, and a lower-compiler, although the exact border
> between the middle and lower compilers is not well defined (the
> lower compiler is mostly whole lots of specific code-generation
> functions, ... whereas the middle compiler is mostly all of the
> "executive logic", ...).


How you ever thought of... starting again? Sometimes you can use the
experience you've gained to produce a simpler and more streamlined version.


--
Bartc

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