Re: a practical UNCOL

> The work of Davidson and Fraser points the way to a practical UNCOL.
> We have been using a register transfer langauge as an intermediate
> language in an optimizing compiler for Smalltalk. Davidson and Fraser
> designed a machine independent peephole optimizer that would translate
> a machine language program into register transfers, optimize the
> resulting program, and combine the transfers back into machine language.


But an RTL really only addresses part of the UNCOL problem, namely one part
of the executable code. There are some knotty problems in the data side--
think about the usual nasties like FORTRAN EQUIVALENCE and other problems
of defining the "memory model" assumed by the intermediate language. Para-
meter passing has been another sticking point--although maybe machines are
more similar now than they were 10-15 years ago. (Does anyone still use
copy/restore for FORTRAN?)


I'll grant that their work *does* suggest some useful progress for the part
of the UNCOL problem it does address.


The trouble with trying to figure out why various UNCOL attempts didn't
succeed is that it's usually not possible to point to any single area and
say "THAT's where the big problem is; that's why it didn't work." It tends
to be a myriad of little problems that overwhelms a putative solution as
it tries to migrate from experimental to practical. (That's also why I was
fussing earlier about OSF's two-machine/one-language requirement--it may
not be enough to find problems.)
---
Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870
[Last time I checked, IBM 370s use copy/restore because the lack of indirect
addressing makes direct reference slow. I suggest that one of the ANDF target
machines for the demo should be one with a wordsize not a power of two. -John]
--

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