I am learning about the original B programming language, but I don't have a compiler.

Is there an emulator for an old computer that can run an old operating system that have a compiler for the original B programming language?


3 Answers 3


I found an LLVM-based implementation of Ken Thompson's PDP-11 flavour of B on GitHub: https://github.com/dobyrch/dbc and also an x86-based implementation of the Honeywell flavour: https://github.com/aap/abc. abc appears to have been reconstructed from documentation, and due to its x86 nature is a little hackish:

Since B was first implemented for machines with word addressing, some hacking was required to make it work on the byte addressed x86. Addresses filled in by the linker are always byte addresses, so pointers to these addresses are collectively stored at the end of the .data section and are then converted to word addresses at runtime, before main() is called.

The generated assembly is very inefficient, not even constant expressions are reduced at compile time. Also I/O is currently not buffered.

However, dbc comes with its own issues:

  • All operators and statements are implemented, although they haven't all been thoroughly tested. I suspect some edge cases with oddly placed labels may generate invalid LLVM IR.
  • Every library function has been implemented, although gtty() and stty() differ slightly from their descriptions in the manual: they both require a 4-word vector as a second argument. They are equivalent to tcgetattr and tcsetattr, respectively, but use a vector instead of struct termios to hold the four flag fields.
  • The error diagnostics still need some work—several different errors may be printed for the same line, and the line number is not always correct.
  • Indirectly assigning to a global variable will have strange results (e.g. foo = 40 is fine, but *&foo = 40 will actually set foo to 5, not 40). This issue does not affect local variable assignment, nor does it affect assignment to array indices (i.e. if foo is a global vector, foo[3] = 40 works as expected). The problem stems from a kludge which is necessary to achieve correct pointer arithmetic semantics.
  • A simple definition may contain at most one value in its initializer list. I have not yet found a reasonable way to implement the semantics described in section 7.1 of the manual; use a vector definition instead (e.g. foo[5] 1, 2, 3, 4, 5; instead of foo 1 2 3 4 5;). Incidentally, this same restriction seemed to be present in the H6070 implementation of B.
  • Global initializer lists may not contain strings or names of other globals (yet).

Unlike ybc, these can both compile some original B programs.


This question has already been asked on Stack Overflow and answered, however we cannot show duplicated across sites. I will link to the answer there:


Which says:

Prompted by this question, there is now a B compiler available from here: https://github.com/Leushenko/ybc

Runs on Windows, Linux, and OSX (binaries provided; in the spirit of the question it is written in an obscure language), where it produces very poor quality x86-32 assembly. Should be GCC-compatible. It is reconstructed out of the available reference material on B, and almost certainly does not reflect the language as it really was in the 1960s. Notably, in the absence of type information (B is untyped), the &a[b] == &*(a + b) rule can not hold on x86, meaning that this task is effectively impossible (without resorting to an interpreter).

Apart from that, Pavel Minaev's comment is right: the language as described is extremely small, far smaller than C, and an experienced/competent compiler programmer could likely write one for you in an afternoon.

Unfortunately this is only a partial answer, as I couldn't tell you where to find a good B compiler.

  • 2
    ybc can't compile contemporary programs, unfortunately.
    – wizzwizz4
    Apr 27, 2019 at 16:54
  • 4
    The answer is wrong about one point.&a[b] == &*(a + b) can hold on x86 without an interpreter. You just need divide addresses by 4 when taking the address of something and multiply them by 4 when dereferencing them. Initialization of global variables is the only problem, you'd likely have to generate code initialize them like with C++ classes.
    – user722
    Apr 27, 2019 at 23:37
  • 1
    FWIW, you can run B code online (uses the linked repo as a base) via Try it Online Apr 28, 2019 at 3:51
  • 1
    @RossRidge it can hold as long as your code doesn't want to interact with values from outside the program, i.e. libc. As soon as you want to call a function like malloc, without type information, B doesn't know whether to divide the return value by four or not. An FFI wrapping all external C functions could fix this, of course. Apr 28, 2019 at 10:15
  • 1
    I can make the &a[b] == &*(a + b) identity hold by assembling a[b] as follows (assuming extrn a,b): mov rsi, [a] ; add rsi, [b], mov rax, [rsi * 8]. That is, we store word addresses and convert word addresses to byte addresses at de-reference time. I can't be bothered to write yet another b compiler though.
    – Joshua
    Apr 28, 2019 at 18:43

Following links in issues for abc(https://github.com/aap/abc/issues/8) has led me to the The Amsterdam Compiler Kit(https://github.com/davidgiven/ack), which lists B as a supported language. It seems to have a more active user community, albeit focused on other languages it supports.

  • 1
    Great find! Welcome to Retrocomputing, and please read the tour.
    – wizzwizz4
    Apr 28, 2019 at 12:33
  • It seems ACK targets only x86_32.
    – vonbrand
    Feb 15, 2021 at 22:37
  • Belatedly (I'm the main ACK maintainer), the ACK actually supports a whole slew of architectures including 8080, 8086, 80386, MIPS, PowerPC, 68000 and VideoCore IV, and the B frontend works on all of them. (Poorly.) Sep 14, 2022 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .