Cfxtrjtrk

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?

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:

https://stackoverflow.com/a/26247672/4370109

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.

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.