[TUHS] Software written in B

segaloco via TUHS tuhs at tuhs.org
Fri Jun 9 01:05:36 AEST 2023

> The signature I would expect from binary B code of this era would be
> that the generated code from each source file starts with a branch (or
> jmp) around the contents of the file, to a "jsr r5, chain" followed by
> a zero terminated list of addresses (which I guessed were addresses of
> address words that needed to be fixed up).

Looking a little closer I think that is what this is, because each file is an a.out header, then a jmp, followed by what I presume is B object code, then the destination of the jmp at that jsr r5 that passes into a routine that I think is then what handles that 0-terminated table of address words.  All of the files have a similar bit up to the data word this opening process increments, so I suspect those are the bounds of brt1, from the opening vector (that the header of the B object jumps to) to the data flag that gets set by the inc operation.

My assumption is that the B objects were stamped with a jmp that simply jumped to whatever the first address past the end was, so then brt1 had to be physically right there to accept flow.  After that point the remaining bits in the B files aren't as similar, but what I can say is I don't see anything on the tail end of these binaries that is consistent enough between them to peg as a brt2.  Instead each seems to be a slightly different jumble of interpreter routines themselves.  At least I think, this is a very high level assessment though, I haven't fully broken any of these into individual parts yet.

By the way, one characteristic of this supposed brt1 code is that it checks that the first word after the jump in the B object is 40022(8) (which is the in-core address of the next word in the B object btw).  If it is not present, or the B runtime did not set the data flag indicated above as the end of brt1, then it simply prints "Init\n" on stdout and exits.  Only if both this B "magic number" and the flag indicating proper entry are set does it seem to proceed rather than just printing Init and exiting.

Not sure what this means, or what the reasoning behind this behavior is, but that explains the "Init" string in each binary, it is also part of the B runtime.

- Matt G.

More information about the TUHS mailing list