Re: UNCOL = Uncool?

Our esteemed moderator writes:
> [You're falling in the classic UNCOL trap: it looks good for some cases,
> we just have to generalize it a little bit. That's always where it fails.


The problems with UNCOL's are always in the details. Having worked on
more than 1 multi-language, multi-target compiler, I have seen this
first hand.


Take for instance a compiler that handles just C and Pascal, two
languages that aren't that far apart in terms of model. Each language
has its own sets of assumptions and implicit optimizations that are
normally built in to the compiler.


You can see this in the __pascal qualifier that is added to VC++
programs to say that certain routines use the Pascal calling sequence
conventions. Why would the calling conventions be different between C
and Pascal? Simply because C allows varargs routines and Pascal
doesn't and in contrast Pascal allows nested procedures with up-level
variable references. Those slight differences mean that entirely
different calling conventions are more efficient (and natural) for the
two different languages.


Making a compiler that handles both situations, requires not only the
calling code to be doubled, but also any code that interacts with
calls and parameters to be increased in complexity also. Now, that's
just one feature. There are many more similarly subtle differences,
for example how strings are represented, what kind of I/O is
supported, how formatting is done.


With just two (or a few languages) this can be mostly worked out.
However, the general solution is that one language is actually the
core and all the others are simply appendages or warts. The two most
famous compiler suites that I worked on had that characteristic.


At Prime Computer the TSI compiler suite supported a wide range of
languages: COBOL, FORTRAN, PL/I, Pascal, Modula-2, Algol, Basic, and
even RPG. However, at it's core it was a PL/I subset G compiler and
sometimes that showed through. The dialect of Pascal that it supported
could pass the ISO conformance suite, but was loaded with PL/I-ish
extensions and saddled with PL/I style strings and structures
(records).


In comparison, the MIPS compiler suite was essentially a Pascal
compiler. Putting things like varargs into it required the resulting
code to be less than optimal for C (in those cases). Now, most of the
time the inefficiencies didn't matter, because most programs use a
subset of the language facilities over most of their code. Thus, the
chance of a tight loop containing a poorly implemented feature are
minimal.


However, when compared to a native compiler for the same language, the
bloat becomes noticeable and hard to rationalize. Thus, as an
implementer, one is always forced to try to find ways to fix the
foreign model to remove those side-effects. That takes even more code
than just getting the feature implemented in the first place. As the
number of languages grows the interactions grow exponentially (if you
want things done efficiently and naturally for each language).


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)

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