Re: Two questions about compiler design

Tom Linden wrote:
> Prime's C front-end was written by Conboy and did indeed conform to
> the PL/I IL and Symbol table design.


Tom's memory is more reliable on mine at this point. I didn't
remember whether Garth Conboy's compiler used the Freiburghouse (TSI
or later "common" as we called it) backend or not--I just knew that
some C compiler did. Garth's compiler is the one that was shipped.


Two things about the Prime architecture are worth mentioning.


One is that pointers and integers were not compatibly sized (at least
not at the beginning)--where byte pointers took up more space (48
bits) in memory than integers (and could actually address individual
bits), but the "integer" part of a pointer couldn't hold a complete
integers worth of values (because some bits in the pointer were part
of the ring security system and the pointer manipulation instructions
would change them on you--setting them to secure values).


Garth actually came up with a neat work-around for this problem, using
the 32 bit word-address only form of the pointer, which had 1 bit in
it which indicated that the extended 48 bit form was used. I don't
know all the details, but essentially he co-opted that 1 bit to mean
other byte (the memory words were 16 bit quantities and thus had two
characters each). I presume when he actually used those pointers as
pointers, he put them in a special location where the actional 16 bits
simply addressed the "other" byte of the word. This gave him pointers
that were "no larger" than integers and could be stored in 32 bit
words (at least when not using them as "pointers"). I think by layout
and padding games he could even puth the 16 bit extensions down in
memory structures in such a way that moving the pointers as 32 bit
quantities would work, but in memory the 16 bits necessary to make
them "real" pointers also was there.


By the time the compiler was shipped, the hardware guys had added a
new instruction to the I-mode instruction set and created a new
instruction set around that model I*-mode. Note, Prime machines had
several different instruction sets they used internally, which
represented different strata in the machines history--there were two
forms of S-mode that corresponded to the original Honeywell (516?)
computers that Primes were originally designed to emulate, R-mode
which added recursive subroutine instructions, V-mode which added
virtual memory, I-mode which added a general register set, and I*-mode
which added character pointers based on Garth's C model. The
interesting thing is that because Prime machines were all micro-coded,
one could switch instruction sets on the fly (e.g. on any call
instruction and I think at other times). The machine booted in one of
the S-modes, but quickly entered R-mode to load the OS, which was
partially in R-mode but mostly in V-mode (while I was there). When
the OS executed user code, it was mostly V-mode or one of the I-modes.


The second point had to do with the Freiburghouse compiler technology,
although it was useful as an UNCOL, it wasn't perfect. The place I
remember this most dramatically was Pascal. We used to internally
call it the Pascal-subset-G compiler, because semantically it matched
the aspects of the PL/I-subset-G (called pl1g) compiler as closely as
it matched Pascal. It had extensions to the Pascal language (as well
as deficiencies) that would have been hard to remove because the
underlying run-time libraries and IL were designed to support PL/I.
As a result of these problems, we used to say (borrowing from a
perfume commercial popular at the time) "Promise them anything but
give them the common backend" our way of talking about the
fundamentals of the code generator, optimizer, and run-time library
that were Freiburghouse based.


> I believe the Ucode is what Hennessey used for the MIPS compilers.


Yes, Fred Chow's compiler was the one Hennessey used for the MIPS
compilers. That same suite was the basis of the DEC Unix compilers,
prior to GEM. It was also used by SGI (at one time; I don't know
about the delta compilers). On an interview with Microsoft, I had
some candid converstations that suggest that at least at one time, one
of the Microsoft C compilers was built on the same technology.


-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
[The VAX VMS C compiler was also built on Freiburghouse's PL/I compiler.
Engineering a Compiler by Anklam et al is mostly about retargeting the
PL/I compiler to the VAX, but at the end there's a short discussion about
the C front end they also wrote and shipped. -John]

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