31st December 2014
Join Date: Jul 2013
Thanked 0 Times in 0 Posts
Originally Posted by roddierod
Now you hit me with TMG! I'm definitely going to look for these books!
notes [30.IX.2014] on TUHS mailing list, about TMG compiler:
> There was a compiler/compiler in use at the Labs, imported I think by Doug
> McIlroy, called TMG.
Sorry for straying from direct Unix history, but this remark spurred a lot
TMG (from "transmogrify", defined in Webster as "to change or alter, often
with grotesque or humorous effect") was imported from Bob McClure, erstwhile
Bell Labs person, then at Texas Instruments. And an interesting import
job it was. McClure had written TMG for the CDC 1604 in machine language. He
sent me green coding sheets hand-transliterated into 7090 code. Interesting
debugging: one knew that the logic of the code was sound, but the opcodes
might not always be right. Sometimes, for example, the wrong one of the two
accumulator-load instructions, CLA and CAL, was used.
Clem Pease converted TMG to the GE 635 for Multics by the artifice of defining
7090 opcodes as 635 macros--sometimes many instructions long to slavishly
emulate the 7090's peculiar accumulator (which mixed 38-bit sign-magnitude
with 37-bit twos-complement and 36-bit ones-complement arithmetic). It's
amusing to speculate about the progressive inflation of TMG had McClure sent
me a similar translation for the 7090.
TMG had a higher-level language written in TMG, which evolved during the
Multics project into something considerably more elaborate than McClure's
original, including features like syntax functions, e.g. seplist(a,b) denoted
a sequence of a's separated by b's, for arbitary syntactic categories a and
b. Syntax functions took TMG beyond the domain of context-free languages.
Multics was to be written in PL/I, a compiler for which was commissioned from
Digitek. They had brilliant Fortran technology, but flubbed PL/I. When it
appeared that the Digitek compiler was hopeless, Bob Morris proposed that
we write a quick and dirty one in TMG. Despite being slow (an interpreter
running on an emulated 7090) and providing only three diagnostics, this
compiler carried the project for a couple of years.
When Unix came along, we were again faced with how to bootstrap TMG across
machines. This time I wrote a bare-bones interpreter in PDP7 assembler, then
by stages grew the language back to the Multics state. Ken, in a compliment
I still treasure, once called this the most amazing program on the original
I believe TMG was involved in the initial evolution of B, but the
real tour-de-force in B was the ability of an interpreted version to
exploit software paging and transcend the limited memory of the PDP-11.
The following scenario was to be repeated several times in the early days
of Unix. When the native version of B ran out of steam, the interpreted
version would be used to introduce some new optimization that would squeeze
the native version back to fit. (Bigger input, smaller output!) Subsequently
we saw the same thing happen with C and the kernel. When the kernel grew
too big, a new optimization would be introduced in C to squeeze it. (And to
squeeze the compiler, too. The compiler, though, never enjoyed B's advantage
of being able temporarily to run in a bigger arena.)