[TUHS] Software written in B

Angelo Papenhoff aap at papnet.eu
Sat Jun 24 00:49:29 AEST 2023

I also stumbled over these language differences.
In my earlier compiler I tried to support all syntax that looked
reasonable, but now I tried to make the code more accurate to the actual
thing. I don't know much about the 6070 version of B and scj didn't
remember many technical details when I asked him about it a few years ago.

For auto vectors you can find an actual example here:

Ken said that the language was the same on the pdp-7 and pdp-11. The
runtime we have for both are different but this must simply reflect
different evolutionary stages rather than platform differences.
I haven't gotten around to building my new compiler yet, but it would be
interesting to see if it's small enough to fit into the 4kw of pdp-7
userspace. The runtime would have to be updated and expanded of course.

In any case it should be fun to run it on v1/v2. Have to try that
on my 11/05 :)

It sure is interesting how many compilers have popped up for B over the
years. I also have a strangely strong love for this little language.


On 23/06/23, Sebastien F4GRX wrote:
> Hi again,
> OK I found your compiler project on github: https://github.com/aap/b
> I see you have introduced changes like this one:
> -       auto ab[500], ava[150];
> -       auto dirf, string, av, name[5], s;
> +       auto ab 1000, ava 150;
> +       auto dirf, string, av, name 5, s;
> So it mean that at some point the auto declaration was changed?
> Oh, yes it was. Here is the original syntax : 
> https://www.bell-labs.com/usr/dmr/www/kbman.html
> And this one describes the use of quotes for auto arrays, but thats for 
> the H6070! https://www.bell-labs.com/usr/dmr/www/bref.pdf
> Also in bref, auto a[4] reserves 5 words, but in ken's version auto a 4 
> reserves 4 words.
> I think I will make a command line option to support both language specs :)
> And fix my code, because I had found this example 
> https://github.com/Spydr06/BCause/blob/main/examples/fibonacci.b
> and was convinced that constants in auto were initial values, but I now 
> understand that this is incorrect.
> Initialized auto variables would have been an avoidable syntactic sugar 
> on these machines!

More information about the TUHS mailing list