Re: What's lacking: a good intermediate form

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]

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