Re: What's lacking: a good intermediate form

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.


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


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


James

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