[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