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?
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?
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()
andstty()
differ slightly from their descriptions in the manual: they both require a 4-word vector as a second argument. They are equivalent totcgetattr
andtcsetattr
, respectively, but use a vector instead ofstruct 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. iffoo
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 offoo 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:
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.
ybc
can't compile contemporary programs, unfortunately.
&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.
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.
Commented
Apr 28, 2019 at 10:15
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.