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?
Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.Sign up to join this community
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.
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
stty()differ slightly from their descriptions in the manual: they both require a 4-word vector as a second argument. They are equivalent to
tcsetattr, respectively, but use a vector instead of
struct termiosto 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 = 40is fine, but
*&foo = 40will 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
foois a global vector,
foo = 40works 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 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).
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:
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.