Re: What's lacking: a good intermediate form

James Harris <james.harris.1@googlemail.com>
Fri, 27 Feb 2009 15:26:42 -0800 (PST)

          From comp.compilers

Related articles
[3 earlier articles]
Re: What's lacking: a good intermediate form pertti.kellomaki@tut.fi (Pertti Kellomaki) (2009-02-27)
Re: What's lacking: a good intermediate form cr88192@hotmail.com (cr88192) (2009-02-27)
Re: What's lacking: a good intermediate form max@gustavus.edu (Max Hailperin) (2009-02-27)
Re: What's lacking: a good intermediate form walter@bytecraft.com (Walter Banks) (2009-02-27)
Re: What's lacking: a good intermediate form bartc@freeuk.com (Bartc) (2009-02-27)
Re: What's lacking: a good intermediate form jon@ffconsultancy.com (Jon Harrop) (2009-02-27)
Re: What's lacking: a good intermediate form james.harris.1@googlemail.com (James Harris) (2009-02-27)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-28)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-28)
Re: What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-28)
Re: What's lacking: a good intermediate form cr88192@hotmail.com (cr88192) (2009-03-01)
Re: What's lacking: a good intermediate form max@gustavus.edu (Max Hailperin) (2009-03-02)
Re: What's lacking: a good intermediate form cr88192@hotmail.com (cr88192) (2009-03-03)
[24 later articles]
| List of all articles for this month |

From: James Harris <james.harris.1@googlemail.com>
Newsgroups: comp.compilers
Date: Fri, 27 Feb 2009 15:26:42 -0800 (PST)
Organization: Compilers Central
References: 09-02-132
Keywords: code, UNCOL
Posted-Date: 28 Feb 2009 06:36:24 EST

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



Post a followup to this message

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