Re: What's lacking: a good intermediate form

Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Thu, 26 Feb 2009 22:06:48 -0700

          From comp.compilers

Related articles
What's lacking: a good intermediate form tony@my.net (Tony) (2009-02-25)
Re: What's lacking: a good intermediate form gah@ugcs.caltech.edu (Glen Herrmannsfeldt) (2009-02-26)
Re: What's lacking: a good intermediate form georgeps@xmission.com (George Peter Staplin) (2009-02-26)
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)
[32 later articles]
| List of all articles for this month |

From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: Thu, 26 Feb 2009 22:06:48 -0700
Organization: Aioe.org NNTP Server
References: 09-02-132
Keywords: code, UNCOL, comment
Posted-Date: 27 Feb 2009 06:26:08 EST

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


I have written here before that a good intermediate form would be
useful to have. Many current processors depend on the compiler to
generate optimal code for the specific processor model or sub-model.


Since the whole idea of processor architecture is that code written to
the architecture will run on any model using that architecture,
dependence on the specific model defeats that goal.


Instead an intermediate code, possibly tuned to the architecture but
not yet for the specific model, could be distributed. Then, at
installation or run time, a processor specific program does the final
code generation from the intermediate code. The conversion program
could even be improved over time, allowing improvements without
recompiling the original program.


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


That is probably true. It is those other 20% that count.


-- glen
[Danger! Danger! This is a famous swamp of no return. Search for many
previous messages with keyword UNCOL. There are some reasonable ILs to
use within a compiler, but a general any-to-any IL has been tried and
failed too many times already. -John]


Post a followup to this message

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