[TUHS] "Notes on the IBM C Compiler" by Mike Lesk
Aron Insinga via TUHS
tuhs at tuhs.org
Wed Jul 15 06:42:47 AEST 2026
Clem, thank you for these details!
Here is the full version of Ron Brender's history of how BLISS was
adopted and evolved by DEC. (Truncated versions have been published
elsewhere.) In recent years BLISS and VMS have been ported by VSI to
the X86_64.
https://archive.org/details/full-bliss-history
And since you mentioned comparison of the BLISS and C generated code,
here's a short paper written by a friend:
https://archive.org/details/bliss-11-a-lesson-in-object-code-optimization/
One of the things I am trying to find so I can scan it is the report by
the Implementation Language Task Force. They knew that C existed but I
don't think they knew much about it and couldn't get it. I don't recall
if they mentioned BCPL but as another typeless language, I'm sure they
would have found that it had no advantage over BLISS. (Really, BLISS-10
was an operator typed language, e.g. different infix operators for
single-precision integer and single-precision floating point addition.
And the bit field operators (X<.p1,.s> = .Y<.p2,.s>) were wonderful for
bit-twiddling. Yeah, the '.' fetch operator was a royal pain.) I
remember that they considered PL/I but thought its compiler would be too
big for DEC computers. I don't recall if they looked at subsets or at
Algol a la Burroughs. But they had BLISS-10 and BLISS-11 to bootstrap
with and Ron's experience from BLISS-11 on how to extend the language
for shorter word-length machines. (Operations on things that don't fit
into a single word are done by reference. There were a bunch of
compile-time constants for bits per word [%BPVAL: 32 for a VAX],
addressing units per word [%UPVAL: 4], and bits per addressing unit
[%BPUNIT: 8], if I remember them correctly; I sure typed them enough.
And there was one heck of a phenomenal compile-time facility/macro
processor. BLISS code could be parameterized for different architectures.)
In later days (at HP or VSI?) some bits of VMS (I don't know which or
how big they were) got rewritten in C from several languages that had
crept in.
Oh, and one lesson for language design: BLISS stopped being an
expression language (LEAVE WITH) at some point, to preserve locality of
reference for the reader. Consider:
X=(IF .condition THEN (
! a lot of code to compute foo
.foo
) ELSE (
! a lot of code to compute bar
.bar
));
! now what did we do with the values of those blocks?
[If I said something conflicting with what Ron wrote, assume he's right
and I had a memory parity error.]
If I may add a diversion about a project that used BLISS and was
influenced by BLISS:
I wrote the compiler for the DECSIM logic simulator's behavior modeling
language compiler. This was a successor to SAGE2's use of, IIRC,
preprocessed BLISS-10: more CMU heritage. DECSIM was to run on both the
36-bit and 32-bit machines so it was all written in Common BLISS. We
were not connected with DEC's compiler groups, so instead of writing 2
code generators, I generated Common BLISS code. I used the green BLISS
book (LEXSYNFLOW and all that) as a guide, and my compiler was *not* a
simple preprocessor; it built an AST, propagated attributes up [like
width of concatenated bit vectors] and down the tree, and finally
traversed the tree emitting the BLISS code for the object code. For
simple things [2-state, 32-bits] it looked like a direct BLISS
translation; a lot of the rest was nested function calls. Co-routines,
where needed for ACTIVATE and WAIT, were done with a big switch
statement taking a 'virtual program counter' to know where to resume
execution; it was simple and I was working alone. It also generated a
binary file of the data descriptors used by the logic simulation engine
and run-time library. Because of the BLISS environment, I hammered the
wishlist into a language by stealing the control flow statements from
BLISS, and adding ACTIVATE and WAIT, but this language had both operator
types and certain data types for logic simulation: 2-state and 4-state
(0, 1, Undefined, and Z/High Impedance) bit vectors, and time. By the
time we were done, I think the 36-bit architectures were cancelled.
(The simulator kernel folks really only wanted the VAX's address space
(for fault simulation) anyway.) I had a short paper in ICCAD -84 and
others (e.g. Sherwood, Ulrich) wrote a lot more papers about DECSIM, but
those were the days that ECAD tools (aside from University projects like
SAGE)were developed internally and kept proprietary in hopes of getting
a competitive advantage from them. Nate Phillips, who wrote the
run-time functions e.g. 4-state operations, spent some time (at
Stanford?) working on logic synthesis and they used the compiler for that.
(Oh, an aside**2, I wanted to call the behavior language Sybil but the
team insisted on a good acronym which I couldn't come up with. (I
thought it was also a fitting from Classical History. I don't remember
what other spellings I tried, if any.) As with JavaScript, I tried
worse names (cf. ECMAScript) but they didn't stick well either. In the
end the CAD tool suite folks came up with .SDS (Structure DECSIM)
instead of .NET and .BDS (Behavior DECSIM) file types and hence language
names, based on the keyword that specified the model type, a bit redundant.)
Anyway, thanks for listening. More info when I find it.
- Aron
On 7/12/26 16:50, Clem Cole via TUHS wrote:
> BLISS was CMU's system programming language, designed by Bill Wulf and his
> students in the late 1960s/early 1970s. The original compiler was a PDP-10
> target (the urban legend is that it was bootstrapped using TECO macros, but
> I don't believe that). BLISS-11 followed a few years later; it was a
> cross-compiler that ran on TOPS-10 (it could not self-host). Compared to
> Dennis's C compiler, a contemporary development, the code it generates makes
> the UNIX C compiler seem almost like a toy (although C could self-host,
> unlike BLISS-11).
>
> In those days, there was very much a belief in the "systems" community that
> you had to write in assembler for any "real" or "production." Famously,
> Wulf took a bunch of his best BLISS programmers and the best PDP-11
> programmers they knew and gave them a bunch of functions/programs to
> write. It turned out that for any code longer than 10 lines of assembler,
> BLISS did as well as or better. The CMU BLISS compiler is discussed in
> the "Green Book," and after that experiment, quickly became the "how-to
> manual" for compiler code generation/optimization:
> [image: BLISS_GreenBook_Cover.png]
> Gordon Bell was on the CMU faculty in those days, and he brought BLISS to
> DEC (and a number of former Wulf's students became the core of the DEC Tech
> Languages Group - TLG). BLISS quickly became the primary system
> programming language for most everything (note Culter hated BLISS - which
> is why VMS was written in assembler, but that's a different story). I've
> written elsewhere about the huge mistake DEC marketing made (they were
> charging $5K per CPU, so too few customers ended up buying it). Yes, the
> ARPA research community (CMU, MIT, Stanford, et al) all had it, as did a
> lot of DOD/DOE contractors, but for the rest of the world, particularly
> universities, when you had the sources to C (and it was self-hosting) and
> came with UNIX all for $100, it wasn't a fair fight. †
>
> As for the IBM 360 family, at some point, one of Gary Kildall's (of CP/M
> fame - remember he was a compiler researcher, not an OS one) students at
> the Naval Postgraduate School wrote a 360 ISA target; but I don't remember
> the OS target for the original 360 compiler. CMU was also famously a
> 360/67 TSS shop. I don't remember if CMU took it back and did the TSS
> support; but it was on our 360/67 (along with PL/360 from Stanford) when I
> worked in the computer center. I think I may still have some of the docs.
>
> Note, Bell Labs was also TSS Shop (ISTR that the original Unix port ran
> under TSS - Tom, did you remember?).
>
> Clem
>
>
> † I've also mentioned I learned BLISS before C and was really disappointed
> with Dennis' compiler when I first saw it. But I quickly joined the C team
> when I realized it was much easier to write and compile programs (the
> PDP-10s and 20s were always way overloaded).
>
> On Sun, Jul 12, 2026 at 3:27 PM John Levine via TUHS<tuhs at tuhs.org> wrote:
>
>> It appears that Tom Lyon via TUHS<pugs78 at gmail.com> said:
>>> I finally managed to extract and format this document.
>>> Read it if you're in to horror literature!
>>>
>>> It comes from the 'memo' file in
>>>
>> https://www.tuhs.org/Archive/Distributions/IBM/370/370_c_virgin_source.tar.gz
>>> PDF here:
>>>
>> https://drive.google.com/file/d/1eVfRW8QS7M11MfK4kFaWRMZLXtuLWjSj/view?usp=sharing
>>
>> I'm intrigued by the references to BLISS on TSS. Is that the same BLISS
>> as on DEC
>> macines? I never heard of a 370 version and neither has Wikipedia.
>>
More information about the TUHS
mailing list