B compiler restored (runnable on v1 unix)

Angelo Papenhoff writes:

…right now I feel that I’ve reach an interesting enough milestone to warrant a separate thread for this here.

First of all, I want to stress that this is still WIP, but everything can be found here now:

In this repo you will find the following:

  • bc and ba that can build themselves
    (I’ve included .s files so everything can be bootstrapped easily).
  • libb and bilib in source form from object/library and binary files of the s2 tape
  • brt1 and brt2 restored from binary files of the s2 tape
  • olibb, obilib and obrt1, older versions of the above
  • a version of ba that does not generate threaded code but an interpreted code more like the pdp-7 code.
    ken told me such a thing existed at one point and indeed it is the only way to fit the compiler into 8kb/4kw
  • an implementation of this interpreted code. With this bc and ba fit into 8kb

Note I have only tested this under apout so far. The version I used needed two tweaks, but see my README.

With this I was able to build the recently reversed B programs [2] and produce exact matches to the originals (modulo assembler differences). In that process I found a few mistakes I made, now the programs are exact.

In the repo you’ll find a B implemented in C and another implemented in B as well as this recreation. From the README:

Having discovered a few B binaries I set out to reconstruct the B compiler as closely as I could and get it to run on UNIX v1. You can find the result in the unix1_bdir directory.

(See also B – A Simple Interpreter Compiler)

Via dragonfly digest


While I do think it’s great to re-create what’s effectively the C compiler bootstrap, I do find it somewhat amusing that this is written in C - the very language B was used to create…

Is there a B compiler in BCPL, I wonder…


How about BCPL compiler in B, instead. :slight_smile:

I don’t think there is. B wasn’t bootstrapped from BCPL, even though B is basically a simplified BCPL. I believe it was bootstrapped on the PDP-7, using assembly language. Rumor has it Ken started doing a Fortran compiler, but changed his mind.

1 Like

That’s the trouble with history - unless it’s written down at the time over time we tend to forget and re-remember things and not always the way it happened but the way we maybe wanted it to happen…

This, I think, is one of the better texts I’ve read on it all:


it’s still fascinating that it was all done on a system with just 8K of memory at the time. I imagine it was easier to hack an existing compiler than write one in another high level language.

What can we do today in 8K?


Well 8K was not what you wanted, it was what you got.I have always wondered why faster small machines where developed rather than slower wider machines with more core. Machines under 24 bits, really are ment for controling things, rather than general purpose computing, something I keep forgetting. The PDP 8 since was 12 bits, gave a good
36 bit floating point number.

36 bits seem best for timesharing, like Multics Multics Wiki or ITS for the PDP 10.

It’s an interesting question… one part of it is the expressiveness of the instruction set and the density of the encoding. One part is the ease or difficulty of the task: both the HLL design and the target instruction set play a part. And then, there’s the skill and ingenuity of the people coding - these stories of the pioneers from the deep past are stories of the exceptional individuals (and teams) who succeeded. We hear less from people who were overwhelmed by the task, or who didn’t even try.

One of the problems in comparing instruction sets (or micros), I think, is that you need to be applying equal amounts of skill to different architectures, and ideally reasonably high levels of skill, if you’re trying to measure expressiveness or density. That’s a high bar. There’s a paper by Weaver and McKee here and presentation here which tries to compare. There’s an updated paper by Weaver here. PDP-11 comes out similar to Z80, I think. (Perhaps see also this thread on 6502.org)

1 Like

Or how about a different B… just found and tossed this ancient ratty “B Newsletter” issue the other day. (probably not the most relevant for this thread but the timing worked for me)

I can’t read the small print, but I see Amsterdam so I assume it’s for the compiler kit. :wink:

How interesting… this B from Amsterdam (Edit: entirely unrelated to C and to the B by Thompson in the USA) became ABC, which in some sense became Python. Your newsletter is issue 1 from 1983. Here’s an article from issue 5 (October 1986) which announces the name change and redesign:

For more on ABC, there’s a packed website here

And speaking of the ACK, the compiler kit, that’s still actively developed, although it looks like it might be fiddly to install it. It has a B front end (I think this is the USA B, not the Amsterdam B), and an Archimedes backend, among a great deal else:

The source is on github (including an example hilo.b), but has previously been on Sourceforge, and the earliest commit apparently predates CVS!

(I hope I haven’t conflated any things with other things of the same name)

Edit: there’s also an article on the Amsterdam B in the User Contributed Software documentation from Mt Xinu, 1986. See page 74 of this pdf.

Maybe we should clarify that “Amsterdam B” is not “Bell Labs B”. And Yes, Guido van Rossum was involved with the Dutch variant. Would it be fair to say it’s a low level language?

EDIT: When I posted this to another medium, Don Hopkins delivered the perfect retort: “Lower than C!”

1 Like