[TUHS] Software written in B

[TUHS] Software written in B

[Sebastien F4GRX]

Hello everyone,

this is my first post on this list.


After looking at the archives for this mailing list, I have seen that 
the B language has been discussed several times already.

After viewing Ken Thompson's interview by Brian Kernighan at VCF East 
2019, I became interested in the B language, as it seemed full-featured 
for system programming, close to C, and simple enough to write a parser 
for it without a code generation tool.

So for fun and self-education, I am now writing a (or yet another) B 
compiler, in C, after reading Jack Crenshaw's "Let's build a compiler" 
documentation ( https://compilers.iecc.com/crenshaw/ )

Here it is: https://git.sr.ht/~f4grx/bpars

It is now starting to generate code for the 68hc11 8-bit platform. It 
can also generate C code.


I have written some test programs, found some B examples, but I thought 
it would be great to use my compiler with actual B software.

Of course, B was a "transition" language, that did not have a continued 
use as soon as it evolved into C. so if any software remains, it will be 
quite hard to find.

And here is my question, is any of you aware of original B source code 
archives? or are in touch with people that would know?


In particular, I read on this document written by Dennis Ritchie: 
https://www.bell-labs.com/usr/dmr/www/chist.html

 > After the TMG version of B was working, Thompson rewrote B in itself 
(a bootstrapping step).


I have also read that the YACC tool was initially written in B.

There might be other historical B sources that I am not aware of.


Do you know if any of this code has survived to this day? Where could I 
find more information about this?


Thank you very much,

Sebastien Lorquet (F4GRX)

[TUHS] Re: Software written in B

[Lars Brinkhoff]

Sebastien F4GRX wrote:
> And here is my question, is any of you aware of original B source code
> archives? or are in touch with people that would know?

Not for Unix, but.

Steven Johnson went on a sabbatical from Bell Labs to Waterloo
University and took B with him.  A group of people there formed a
company which still offers B for GCOS.
https://www.thinkage.ca/gcos/expl/b/manu/manu.html

The original AberMUD was written by Alan Cox (of Linux fame) et al in B.
A paper listing exists but has yet to be scanned.  I collected some
scraps here:
https://github.com/larsbrinkhoff/abermud/tree/master/abermud1

Some other people also writing B compilers:
https://github.com/aap/b
https://github.com/DavidSkrundz/B

[TUHS] Re: Software written in B

[Angelo Papenhoff]

Sebastien,
I'm not aware of any old UNIX B code beyond the examples from the
documentation and one or two short programs for the PDP-7 (this is older
B).

As Lars already mentioned, some people have written their own B
compilers, even in B.
My compiler (https://github.com/aap/b) generates the same threaded
code that ran on the PDP-11 and I implemented it on a few platforms,
(pdp-11, amd64, mips32, riscv64), notably it runs on UNIX v6. 
Robert Swierczek has written a B compiler that is compatible with the
PDP-7 runtime:
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/b.b

With B you pretty much have to write your own code unfortunately. Would
be great if some bigger programs (like the compiler and yacc) were found.

best,
Angelo

On 07/06/23, Sebastien F4GRX wrote:
> Hello everyone,
> 
> this is my first post on this list.
> 
> 
> After looking at the archives for this mailing list, I have seen that 
> the B language has been discussed several times already.
> 
> After viewing Ken Thompson's interview by Brian Kernighan at VCF East 
> 2019, I became interested in the B language, as it seemed full-featured 
> for system programming, close to C, and simple enough to write a parser 
> for it without a code generation tool.
> 
> So for fun and self-education, I am now writing a (or yet another) B 
> compiler, in C, after reading Jack Crenshaw's "Let's build a compiler" 
> documentation ( https://compilers.iecc.com/crenshaw/ )
> 
> Here it is: https://git.sr.ht/~f4grx/bpars
> 
> It is now starting to generate code for the 68hc11 8-bit platform. It 
> can also generate C code.
> 
> 
> I have written some test programs, found some B examples, but I thought 
> it would be great to use my compiler with actual B software.
> 
> Of course, B was a "transition" language, that did not have a continued 
> use as soon as it evolved into C. so if any software remains, it will be 
> quite hard to find.
> 
> And here is my question, is any of you aware of original B source code 
> archives? or are in touch with people that would know?
> 
> 
> In particular, I read on this document written by Dennis Ritchie: 
> https://www.bell-labs.com/usr/dmr/www/chist.html
> 
>  > After the TMG version of B was working, Thompson rewrote B in itself 
> (a bootstrapping step).
> 
> 
> I have also read that the YACC tool was initially written in B.
> 
> There might be other historical B sources that I am not aware of.
> 
> 
> Do you know if any of this code has survived to this day? Where could I 
> find more information about this?
> 
> 
> Thank you very much,
> 
> Sebastien Lorquet (F4GRX)
> 

[TUHS] Re: Software written in B

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3042 bytes --]

I recall a couple of editors and some tools were kicking around written in
B.  I would check the GCOS archives, as I believe that for a long time, B
was a popular systems programming language for that OS target.  B might
have been moved to Multics, but I have no memory of seeing it.   IIRC, most
system programming there was on in its powerful PL/1 dialect or a
Fortran/often with a preprocessor like MORTRAN or RatFor, which I did see.

Interestingly, I also have no memory of a B implementation for the PDP-10,
which like GE/Honeywell systems, was 36-bit, word addressed. I used BLISS
and SAIL on those, if not the assembler.

FWIW: Besides C, B also begat two other languages Eh and Zed, both at
Waterloo,  Eh I believe, was what the original Thoth system was written,
although it might have had some utilities in B; you have to ask someone
like Mike Malcom.  Since many/most of the 1970s mini's and later micro's,
ISAs were byte addressed, the word nature of B (and the fact that the
source to Ritchie C compiler came with UNIX), is probably what caused it to
have a more limited life.
ᐧ

On Wed, Jun 7, 2023 at 6:14 AM Sebastien F4GRX <f4grx@f4grx.net> wrote:

> Hello everyone,
>
> this is my first post on this list.
>
>
> After looking at the archives for this mailing list, I have seen that
> the B language has been discussed several times already.
>
> After viewing Ken Thompson's interview by Brian Kernighan at VCF East
> 2019, I became interested in the B language, as it seemed full-featured
> for system programming, close to C, and simple enough to write a parser
> for it without a code generation tool.
>
> So for fun and self-education, I am now writing a (or yet another) B
> compiler, in C, after reading Jack Crenshaw's "Let's build a compiler"
> documentation ( https://compilers.iecc.com/crenshaw/ )
>
> Here it is: https://git.sr.ht/~f4grx/bpars
>
> It is now starting to generate code for the 68hc11 8-bit platform. It
> can also generate C code.
>
>
> I have written some test programs, found some B examples, but I thought
> it would be great to use my compiler with actual B software.
>
> Of course, B was a "transition" language, that did not have a continued
> use as soon as it evolved into C. so if any software remains, it will be
> quite hard to find.
>
> And here is my question, is any of you aware of original B source code
> archives? or are in touch with people that would know?
>
>
> In particular, I read on this document written by Dennis Ritchie:
> https://www.bell-labs.com/usr/dmr/www/chist.html
>
>  > After the TMG version of B was working, Thompson rewrote B in itself
> (a bootstrapping step).
>
>
> I have also read that the YACC tool was initially written in B.
>
> There might be other historical B sources that I am not aware of.
>
>
> Do you know if any of this code has survived to this day? Where could I
> find more information about this?
>
>
> Thank you very much,
>
> Sebastien Lorquet (F4GRX)
>
>

[-- Attachment #2: Type: text/html, Size: 4451 bytes --]

[TUHS] Re: Software written in B

[Lars Brinkhoff]

Clem Cole <clemc@ccc.com> writes:
> Interestingly, I also have no memory of a B implementation for the PDP-10,
> which like GE/Honeywell systems, was 36-bit, word addressed.

PDP-10 had BCPL (two!) which was somewhat popular, so maybe it did't
need a pared-down version.  Same goes for TX-2 if you want to talk
36-bit (who doesn't).

> I used BLISS and SAIL on those, if not the assembler.

SAIL begat Mainsail, wich in theory could still be around today...
for Unix, he said on-topicly!

[TUHS] Re: Software written in B

[Bakul Shah]

Then there is Arthur Whitney's B language. This is a *completely*
different beast from Ken Thompson's B.

https://web.archive.org/web/20160505183405/http://kparc.com/b/

Here's binary search in it:
  b[Ii]{h:#x;l:0;while(h>l)$[y>x[i:/l+h];l:i+1;h:i];l}
for comparison here it is in C:
  I b(I*x,I y){I h=x[-1],i,l=0;while(h>l)if(y>x[i=l+h>>1])l=i+1;else h=i;R l;}

[B is modeled after his K language, hence the extreme terseness]

Perhaps not most people's cup of tea but certainly interesting. Too bad
no one else has dared to pick it up! :)/2

> On Jun 7, 2023, at 3:14 AM, Sebastien F4GRX <f4grx@f4grx.net> wrote:
> 
> So for fun and self-education, I am now writing a (or yet another) B compiler, in C, after reading Jack Crenshaw's "Let's build a compiler" documentation ( https://compilers.iecc.com/crenshaw/ )
> 
> Here it is: https://git.sr.ht/~f4grx/bpars

[TUHS] Re: Software written in B

[Phil Budne]

Here's what I know about surviving early UNIX B implementations bits:

Two surviving B programs from PDP-7 UNIX listings:
https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/ind.b
https://github.com/DoctorWkt/pdp7-unix/blob/master/scans/lcase.b

NOT a b program, but for "fun" I tried my hand at recreating the TMG
compiler compiler for the PDP-7 (we only have the original library
routines, but not the TMG (.t) source for the compiler at:

https://github.com/philbudne/pdp7-unix/tree/tmg/src/other/pbtmg and
tried writing a B compiler in TMG (b.t in the above directory) based
on Robert Swierczek's decoding of the B interpreter/runtime.

Both the PDP-7 and (initial?) PDP-11 B compilers generated interpreted code.

I'm not aware if the PDP-11 B compiler source has ever been unearthed,
but a ar(chive) file of the library and interpreted was found, and
Robert S posted disassemblies here:

https://github.com/rswier/pdp11-B/

With this explanation of where the files were discovered:
https://github.com/rswier/pdp11-B/tree/master/fs

As well as
http://squoze.net/B/bilib/

Which I added to Robert's tree in a private branch that I guess
I never opened a Pull Request for:
https://github.com/philbudne/pdp11-B/tree/pb/source/bilib

And I (think) I had to make up brt1.s and brt2.s files:
https://github.com/philbudne/pdp11-B/blob/pb/source/brt/brt1.s
https://github.com/philbudne/pdp11-B/blob/pb/source/brt/brt2.s

based on the usage description in Ken's manual:
https://www.bell-labs.com/usr/dmr/www/kbman.html :
	ld object /etc/brt1 -lb /etc/bilib /etc/brt2

I tried to hack Robert's PDP-7 B compiler to work with the above
PDP-11 runtime:
https://github.com/philbudne/pdp11-B/blob/pb/source/b711/

But I don't remember what state I left it in.

Ken's manual indicates that the original PDP-11 B compiler had two
phases: "bc" which generated intermediate code, and "ba" which turned
that into a .s file.

A "fun fact" about all the above compilers (TMG and B) for both the
PDP-7 and the PDP-11 is that the compilers (eventually) output
assembly language source that was assembled (and for the PDP-11
loaded) with an interpreter library and runtime.

I seem to recall that for the PDP-7, the interpreted code (for both
TMG and B) looks much like PDP-7 instructions (same number of high
order "opcode" bits, some use of the indirect bit, and an address
field while the PDP-11 B compiler (at least) generated code is more
like threaded code, with an interpreter program counter in r3, and
"jmp *(r3)+" to dispatch to the next instruction.

[TUHS] Re: Software written in B

[Andrew Hume]

i was in 1127 in 1981 (for an internship) and then from 1983 onwards.
the only B code i saw or knew of was the driver code that ran in the
Linotron typesetter. it ran on an 8in floppy and my recollection is
that the thing that mattered most was its very small run-time support.
i’m pretty sure it was Ken’s code but i never knew any other details.

[TUHS] Re: Software written in B

[segaloco via TUHS]

> Of course, B was a "transition" language, that did not have a continued
use as soon as it evolved into C. so if any software remains, it will be
quite hard to find.

There is a bit of binary code from that transition period that may hold some answers.  In my disassembly of the s2-bits binaries (V2-ish), I've come across the following that bear a particular signature I can't identify otherwise:

echo, exit, glob, goto, if, mail, skip, stty, su

This "signature" I refer to being a few properties of the a.out files and initial flow of the entry compared with other binaries of known source code origin.  First, these are all magic number 405(8) binaries, so V1 era a.out.  Second, in each case, the initial branch is to a jump vector which then performs a r5-relative subroutine call followed by a halt in the case of fallthrough.  In other words:

    br  _start  / 405(8)
    ...
_start:
    jmp innerstart    / some faraway place
    ...
innerstart:
    jsr r5,main    / always 004567 000042
    halt
    ...
main:
    inc somevalue   / always 005267 000136 or 005267 000140
    ...

Finally, these all appear to have the four characters "Init" strewn in there with a bunch of binary data.  It is consistently in all of the above binaries exhibiting these other two patterns.  I don't have any confirmed B code/binaries to compare against, so I can't say that this is a signature of B, but it is a signature of *something*.  Whatever it is these all share it.

This can be compared with disassembly of programs like:

    - ln, a "naked" binary in that it has no a.out header that immediately calls break
    - chown, a V1 a.out (magic number 405(8)) that jumps immediately into the assembly routine
    - find, a V2 a.out (magic number 407(8)) that does the same
    - fc, a V2 a.out compiled from C that branches into a crt0 startup that then jumps to main, this crt0 startup matches the crt0.o file in s2-bits

Something of note too with the above programs is that the earliest preserved versions of each are all in C.  That being exit, glob, goto, and if from the s1-bits tape (V3-ish) as well as echo, mail, stty, and su in V5 (not sure what skip is/was).  This is all pretty compelling, but conjecture nonetheless.  Perhaps it will draw hard proof closer.

- Matt G.

P.S., these are the other s2-bits binaries by "signature":

    - naked - cal, chmod, dsw, ln, rm
    - V1 asm - :, ar, bas, cat, chball, check, chown, cmp, cp, date, db, dc, df, du, ed, form, getty, init, login, ls, mesg, mkdir, msh, mv, od, pr, rew, rmdir, roff, sh, sort, stat, sum, tap, tm, tty, wc, who, write
    - V2 asm - as, as2, ds, find, ld, maki, nm, strip, un
    - V2 C - cc, fc, size

[TUHS] Re: Software written in B

[Phil Budne]

An unpleasant aspect of B on the PDP-11 seemed to be that data
addresses were stored as "word addresses" (divided by two).  Addresses
"fix ups" were done before starting any user or other run-time code.

I wrote a comment about this at
https://github.com/philbudne/pdp11-B/blob/pb/source/brt/brt1.s#L67

(which is my reconstruction of the brt files).  Alas, I didn't note
the origin of the SCJ recollection of DMR's hack.

B code from "libb" (disassembled by Angelo Papenhoff?) shows the
initial branch:

http://squoze.net/B/libb/printf.s
http://squoze.net/B/libb/printn.s

Although neither file has any fixups.

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).

I would expect the code at "chain" to loop through the words
referenced by (r5)+ "fixing" them, and finally returning using "rts r5",
something like the code I wrote at
https://github.com/philbudne/pdp11-B/blob/pb/source/brt/brt1.s#L102

chain:	mov	(r5)+,r0	// fetch pointer pointer
	beq	1f		// quit on zero word
	asr	(r0)		// adjust the referenced word
	br	chain

1:	rts	r5		// return to end of file, fall into next

If the utilities you mention were in fact written in B (which would
offer us the chance to recover the actual code used in brt1 and brt2)

Which looks VERY MUCH like what you describe:
> This "signature" I refer to being a few properties of the a.out files and initial flow of the entry compared with other binaries of known source code origin.  First, these are all magic number 405(8) binaries, so V1 era a.out.  Second, in each case, the initial branch is to a jump vector which then performs a r5-relative subroutine call followed by a halt in the case of fallthrough.  In other words:
>
>     br  _start  / 405(8)
>     ...
> _start:
>     jmp innerstart    / some faraway place
>     ...
> innerstart:
>     jsr r5,main    / always 004567 000042
>     halt
>     ...
> main:
>     inc somevalue   / always 005267 000136 or 005267 000140
>     ...

The fact that the jsr r5 always points to a small, fixed address is
likely because it points to B runtime code loaded at the start of
memory, which doesn't exactly match what's described in section 10.0
in https://www.bell-labs.com/usr/dmr/www/kbman.html:

	ld object /etc/brt1 -lb /etc/bilib /etc/brt2

The initial jmp is the file prologue emitted by the B compiler,
and the code at "innerstart" the epilogue, that I would expect
to be "jsr r5, chain"

I believe the "halt" is a literal zero word (terminating the fixup
list) and not a halt instruction, and that the chain routine (auto)
increments r5, until it sees a zero word, and then returns
(likely via "rts r5") to the word after the zero word.

[TUHS] Re: Software written in B

[arnold]

Andrew Hume <andrew@humeweb.com> wrote:

> i was in 1127 in 1981 (for an internship) and then from 1983 onwards.
> the only B code i saw or knew of was the driver code that ran in the
> Linotron typesetter. it ran on an 8in floppy and my recollection is
> that the thing that mattered most was its very small run-time support.
> i’m pretty sure it was Ken’s code but i never knew any other details.
>

See https://www.cs.princeton.edu/~bwk/202/ for info about the Linotron
and Ken's code. Great reading, both the original memo and the story
behind reconstructing it.

Arnold

[TUHS] Re: Software written in B

[segaloco via TUHS]

> 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.

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hello,

You have sent me a lot of valuable information about all of this 
software environment, some of which I had already found, but most is new 
for me. It was extremely interesting to read.

In particular I had seen the GCOS documentation, but did not consider 
deeply because they seem to describe a much improved and extended B 
language.

I am able to contact Alan Cox (aka EtchedPixels) via Mastodon, I will 
ask him about AberMUD.

Thank you Phil Budne for the PDP-7 listings, it's amazing to see that 
these two are even older since they use $( )$ instead of braces for 
compound statements.

And the linotron saga is absolutely fantastic!

Thank you everyone!

Sebastien


Le 07/06/2023 à 12:14, Sebastien F4GRX a écrit :
> Hello everyone,
>
> this is my first post on this list.
>
>
> After looking at the archives for this mailing list, I have seen that 
> the B language has been discussed several times already.
>
> After viewing Ken Thompson's interview by Brian Kernighan at VCF East 
> 2019, I became interested in the B language, as it seemed 
> full-featured for system programming, close to C, and simple enough to 
> write a parser for it without a code generation tool.
>
> So for fun and self-education, I am now writing a (or yet another) B 
> compiler, in C, after reading Jack Crenshaw's "Let's build a compiler" 
> documentation ( https://compilers.iecc.com/crenshaw/ )
>
> Here it is: https://git.sr.ht/~f4grx/bpars
>
> It is now starting to generate code for the 68hc11 8-bit platform. It 
> can also generate C code.
>
>
> I have written some test programs, found some B examples, but I 
> thought it would be great to use my compiler with actual B software.
>
> Of course, B was a "transition" language, that did not have a 
> continued use as soon as it evolved into C. so if any software 
> remains, it will be quite hard to find.
>
> And here is my question, is any of you aware of original B source code 
> archives? or are in touch with people that would know?
>
>
> In particular, I read on this document written by Dennis Ritchie: 
> https://www.bell-labs.com/usr/dmr/www/chist.html
>
> > After the TMG version of B was working, Thompson rewrote B in itself 
> (a bootstrapping step).
>
>
> I have also read that the YACC tool was initially written in B.
>
> There might be other historical B sources that I am not aware of.
>
>
> Do you know if any of this code has survived to this day? Where could 
> I find more information about this?
>
>
> Thank you very much,
>
> Sebastien Lorquet (F4GRX)
>

[TUHS] Re: Software written in B

[Lars Brinkhoff]

Sebastien F4GRX wrote:
> I am able to contact Alan Cox (aka EtchedPixels) via Mastodon, I will
> ask him about AberMUD.

He may refer you to Alec Muffett, who has a paper listing:
https://alecmuffett.com/article/12714

[TUHS] Re: Software written in B

[Angelo Papenhoff]

Thank you two for finding this!
I did some disassembling yesterday and have uploaded brt1.s and brt2.s
to my site now: http://squoze.net/B/brt/ (I haven't actually assembled
them yet, there may be mistakes)

Some observations:

- The 'chain' format is actually a linked list and not a list of
addresses. Phil and I both got this wrong.

- The "Init" string is an error message if for some reason the B init
chain didn't run or main doesn't look like a function

- The cmdline arguments overwrite part of the init code. There's about
80 bytes of space for them before it overwrites the code that builds the
argv vector

- brt2.s is only to mark the beginning of the stack


I also saw some differences in the bilib code but haven't really
analyzed that part (yet?)

Would be really great if we could get all the files disassembled and
decompiled and restore the source code for everything :)

Best,
Angelo

On 08/06/23, segaloco via TUHS wrote:
> > 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.

[TUHS] Re: Software written in B

[Angelo Papenhoff]

After writing this mail I actually started reversing the B binaries.
You can find them here: http://squoze.net/B/programs/

I did find some differences in versions of the B runtime and library.
Especially interesting was an implementation of the cksto routine
in su and stty that checks whether an address in an assignment is in a
reasonable range ("LV out of range" error if not)

What is perhaps interesting historically is that the su binary contains
a hardcoded password ^Q^R^S^T, which is not printable for a good reason:
it is given as a command line argument.

I will hopefully continue with this in the next time (if, goto, mail and
glob are left).

Best,
aap

On 14/06/23, Angelo Papenhoff wrote:
> Thank you two for finding this!
> I did some disassembling yesterday and have uploaded brt1.s and brt2.s
> to my site now: http://squoze.net/B/brt/ (I haven't actually assembled
> them yet, there may be mistakes)
> 
> Some observations:
> 
> - The 'chain' format is actually a linked list and not a list of
> addresses. Phil and I both got this wrong.
> 
> - The "Init" string is an error message if for some reason the B init
> chain didn't run or main doesn't look like a function
> 
> - The cmdline arguments overwrite part of the init code. There's about
> 80 bytes of space for them before it overwrites the code that builds the
> argv vector
> 
> - brt2.s is only to mark the beginning of the stack
> 
> 
> I also saw some differences in the bilib code but haven't really
> analyzed that part (yet?)
> 
> Would be really great if we could get all the files disassembled and
> decompiled and restore the source code for everything :)
> 
> Best,
> Angelo

[TUHS] Re: Software written in B

[segaloco via TUHS]

Angelo, do you mind if I mirror these disassembles into my https://gitlab.com/segaloco/v2src repository?  That's where I'm (very slowly) accumulating the results of mt own disassembly efforts on the V2 binaries.  Bonus points if you raise a PR, but I can make sure you get a shout-out in the Readme or something otherwise.  Thanks for digging deeper where I haven't found the time.

- Matt G.

------- Original Message -------
On Wednesday, June 14th, 2023 at 1:03 PM, Angelo Papenhoff <aap@papnet.eu> wrote:


> After writing this mail I actually started reversing the B binaries.
> You can find them here: http://squoze.net/B/programs/
> 
> I did find some differences in versions of the B runtime and library.
> Especially interesting was an implementation of the cksto routine
> in su and stty that checks whether an address in an assignment is in a
> reasonable range ("LV out of range" error if not)
> 
> What is perhaps interesting historically is that the su binary contains
> a hardcoded password ^Q^R^S^T, which is not printable for a good reason:
> it is given as a command line argument.
> 
> I will hopefully continue with this in the next time (if, goto, mail and
> glob are left).
> 
> Best,
> aap
> 
> On 14/06/23, Angelo Papenhoff wrote:
> 
> > Thank you two for finding this!
> > I did some disassembling yesterday and have uploaded brt1.s and brt2.s
> > to my site now: http://squoze.net/B/brt/ (I haven't actually assembled
> > them yet, there may be mistakes)
> > 
> > Some observations:
> > 
> > - The 'chain' format is actually a linked list and not a list of
> > addresses. Phil and I both got this wrong.
> > 
> > - The "Init" string is an error message if for some reason the B init
> > chain didn't run or main doesn't look like a function
> > 
> > - The cmdline arguments overwrite part of the init code. There's about
> > 80 bytes of space for them before it overwrites the code that builds the
> > argv vector
> > 
> > - brt2.s is only to mark the beginning of the stack
> > 
> > I also saw some differences in the bilib code but haven't really
> > analyzed that part (yet?)
> > 
> > Would be really great if we could get all the files disassembled and
> > decompiled and restore the source code for everything :)
> > 
> > Best,
> > Angelo

[TUHS] Re: Software written in B

[Angelo Papenhoff]

Sure, go ahead. I hope I will have more soon.

On 14/06/23, segaloco wrote:
> Angelo, do you mind if I mirror these disassembles into my https://gitlab.com/segaloco/v2src repository?  That's where I'm (very slowly) accumulating the results of mt own disassembly efforts on the V2 binaries.  Bonus points if you raise a PR, but I can make sure you get a shout-out in the Readme or something otherwise.  Thanks for digging deeper where I haven't found the time.
> 
> - Matt G.
> 
> ------- Original Message -------
> On Wednesday, June 14th, 2023 at 1:03 PM, Angelo Papenhoff <aap@papnet.eu> wrote:
> 
> 
> > After writing this mail I actually started reversing the B binaries.
> > You can find them here: http://squoze.net/B/programs/
> > 
> > I did find some differences in versions of the B runtime and library.
> > Especially interesting was an implementation of the cksto routine
> > in su and stty that checks whether an address in an assignment is in a
> > reasonable range ("LV out of range" error if not)
> > 
> > What is perhaps interesting historically is that the su binary contains
> > a hardcoded password ^Q^R^S^T, which is not printable for a good reason:
> > it is given as a command line argument.
> > 
> > I will hopefully continue with this in the next time (if, goto, mail and
> > glob are left).
> > 
> > Best,
> > aap

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hello,

That is really interesting, thank you for providing that.

I see that su.b contains non-ascii characters ($11,$12,$13,$14) which 
tripped my linux console when I attempted a copy paste, since $13 is 
XOFF :) Is there a way to escape these characters? Or update them, since 
it looks like a password provided on command line.

In its current state my compiler managed to eat all these sources except 
goto which segfaults for a reason I have not determined yet.


May I have your authorization for copying these files into my own b 
compiler repository ( https://git.sr.ht/~f4grx/bpars )? What licence and 
attribution info shall I indicate?

Sebastien


PS: here is the 68hc11 assembly that the current version of my B 
compiler generates for echo.b. Code is still not functional, parameters 
and locals are not allocated, but instructions are consistent.

this mcu is similar to 6502 and other cpus in the motorola 6800 line: 
two 8-bit accumulators A,B combinable into D, and two 16-bit index reg X 
and Y (Y is not used), 16-bit SP.

/*---------------------------------------------------------------------------*/
         .text
         .global main
         .func   main
main:
#function has no args
#local var i size 2 stack offset 0 TODO
#total stack frame size for compound: 2
         LDD     #1
         STD     i        /*Direct assign - local*/
.Lwhile_1:
/*binop, both complex*/
/*generate RHS in D, then move in temp*/
in gen_index: computing base expression (as lvalue)
in gen_index: lvalue=1
         LDX     #argv /*lvalue-extern*/
in gen_index: computing base expression done
         LDD     0,X
         PSHB
         PSHA
/*generate LHS in D*/
         LDX     #i /*lvalue-local*/
         LDD     0,X     /*Get value in X for easy 16-bit op*/
         XGDX    /*Now value is in X and address in D*/
         INX     /*Do the preinc*/
         XGDX    /*Now updated value is in D and address in X*/
         STD     0,X     /*Save the new value, next code can use it*/
/*execute*/
         PULX    /*--- Recall complex B computed before */
         STX     TEMP    /*---put in temp for binop*/
         CPD     TEMP
         BGT     .Lcond2
#start emit arglist for call
         .section .rodata
.strconst_3:
         .asciz "%s "
         .text
         LDD     #.strconst_3
         PSHB    /*argoff=0*/
         PSHA
in gen_index: computing base expression (as lvalue)
in gen_index: lvalue=1
         LDX     #argv /*lvalue-extern*/
in gen_index: computing base expression done
         LDD     i /*local*/
         LSLD
         STX     TEMP
         ADDD    TEMP
         XGDX
         LDD     0,X
         PSHB    /*argoff=2*/
         PSHA
#end emit arglist, size=4
         JSR     printf  /*undef*/
         PULX
         PULX
/*end of loop, eval condition again*/
         BRA     .Lwhile_1
.Lcond_2:
#start emit arglist for call
         LDD     #10
         PSHB    /*argoff=0*/
         PSHA
#end emit arglist, size=2
         JSR     putchar /*undef*/
         PULX
.Lstmtend_0: /*TODO avoid generating this if the statement does not 
contain breaks (no need for recursion)*/
.Lmain__rts: /* TODO avoid this label if statement contains no return */
         RTS
         .endfunc        # main


Le 14/06/2023 à 22:03, Angelo Papenhoff a écrit :
> After writing this mail I actually started reversing the B binaries.
> You can find them here: http://squoze.net/B/programs/
>
> I did find some differences in versions of the B runtime and library.
> Especially interesting was an implementation of the cksto routine
> in su and stty that checks whether an address in an assignment is in a
> reasonable range ("LV out of range" error if not)
>
> What is perhaps interesting historically is that the su binary contains
> a hardcoded password ^Q^R^S^T, which is not printable for a good reason:
> it is given as a command line argument.
>
> I will hopefully continue with this in the next time (if, goto, mail and
> glob are left).
>
> Best,
> aap
>
> On 14/06/23, Angelo Papenhoff wrote:
>> Thank you two for finding this!
>> I did some disassembling yesterday and have uploaded brt1.s and brt2.s
>> to my site now: http://squoze.net/B/brt/ (I haven't actually assembled
>> them yet, there may be mistakes)
>>
>> Some observations:
>>
>> - The 'chain' format is actually a linked list and not a list of
>> addresses. Phil and I both got this wrong.
>>
>> - The "Init" string is an error message if for some reason the B init
>> chain didn't run or main doesn't look like a function
>>
>> - The cmdline arguments overwrite part of the init code. There's about
>> 80 bytes of space for them before it overwrites the code that builds the
>> argv vector
>>
>> - brt2.s is only to mark the beginning of the stack
>>
>>
>> I also saw some differences in the bilib code but haven't really
>> analyzed that part (yet?)
>>
>> Would be really great if we could get all the files disassembled and
>> decompiled and restore the source code for everything :)
>>
>> Best,
>> Angelo

[TUHS] Re: Software written in B

[Angelo Papenhoff]

On 15/06/23, Sebastien F4GRX wrote:
> I see that su.b contains non-ascii characters ($11,$12,$13,$14) which 
> tripped my linux console when I attempted a copy paste, since $13 is 
> XOFF :) Is there a way to escape these characters? Or update them, since 
> it looks like a password provided on command line.

The last1120 C compiler does not have an escape mechanism for strings,
so it's highly unlikely the B compiler had it.

> May I have your authorization for copying these files into my own b 
> compiler repository ( https://git.sr.ht/~f4grx/bpars )? What licence and 
> attribution info shall I indicate?

Sure, sure. I reversed goto.b today and am currently working on if.b. So
just keep an eye on the files.

best,
Angelo

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hello again,

OK for the absence of escapes. It's not a big deal.

And thank you for the authorization. I will surely follow your progress.


There is a typo in your goto.b decompilation, an AND operator is missing 
before testing for end of string, here is a patch:


diff --git a/examples/squoze_goto.b b/examples/squoze_goto.b
index bb39e66..8d48bb3 100644
--- a/examples/squoze_goto.b
+++ b/examples/squoze_goto.b
@@ -31,7 +31,7 @@ l:
                 goto l;
                 }
         while ((ch=getchar())==' ');
-       while (ch!=' ' & ch!='*n' ch!='*0') {
+       while (ch!=' ' & ch!='*n' & ch!='*0') {
                 lchar(s, i++, ch);
                 ch = getchar();
         }


Sebastien

Le 15/06/2023 à 10:21, Angelo Papenhoff a écrit :
> On 15/06/23, Sebastien F4GRX wrote:
>> I see that su.b contains non-ascii characters ($11,$12,$13,$14) which
>> tripped my linux console when I attempted a copy paste, since $13 is
>> XOFF :) Is there a way to escape these characters? Or update them, since
>> it looks like a password provided on command line.
> The last1120 C compiler does not have an escape mechanism for strings,
> so it's highly unlikely the B compiler had it.
>
>> May I have your authorization for copying these files into my own b
>> compiler repository ( https://git.sr.ht/~f4grx/bpars )? What licence and
>> attribution info shall I indicate?
> Sure, sure. I reversed goto.b today and am currently working on if.b. So
> just keep an eye on the files.
>
> best,
> Angelo

[TUHS] Re: Software written in B

[Angelo Papenhoff]

Update: I'm now done with the first pass of this.
I reversed all the programs and successfully ran them through my
compiler (i haven't assembled or linked anything though).
http://squoze.net/B/programs/

To check for correctness, the files should of course be compiled,
assembled and linked again. Unfortunately my compiler currently
does not generate quite the same code as the original one. I will
have to work on this.
Most importantly & and | are only bitwise operators in the version
of B that compiled these programs, but some other differences (like
the fixup chain and the way strings are stored) exist too.

It would be nice to have a fully working B system on v1/v2 UNIX again,
with everything built from source, we can even reconstruct different
versions of the runtime (and perhaps standard library). So far the
PDP-11 version of my B system has only run on v6 and 2.11BSD.

best,
aap

On 14/06/23, Angelo Papenhoff wrote:
> I will hopefully continue with this in the next time (if, goto, mail and
> glob are left).

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hello,


my own compiler choked on if.b and mail.b because of this invalid 
expression in nxtarg:

if(ap>ac) return(0*ap++);


I believe it should instead read:

if(ap>ac) return 0;


What do you think about this?


PS: The original code gives this AST which shows how my compiler 
interprets this source :

function name nxtarg
.  env: ref to function nxtarg
.  env: ref to function main
.  compound stmt
.  .  env: extern ap
.  .  env: extern ac
.  .  env: extern argv
.  .  env: ref to function nxtarg
.  .  env: ref to function main
.  .  if test
.  .  .  operation: GT
.  .  .  .  extern declaration ap
.  .  .  .  extern declaration ac
.  .  then stmt
.  .  .  return stmt
.  .  .  .  operation: MUL
.  .  .  .  .  value: 0
.  .  .  .  .  operation: POSTINC
.  .  .  .  .  .  extern declaration ap
.  .  return stmt
.  .  .  [LVALUE] operation: INDEX
.  .  .  .  extern declaration argv
.  .  .  .  operation: POSTINC
.  .  .  .  .  extern declaration ap

Sebastien


Le 17/06/2023 à 10:19, Angelo Papenhoff a écrit :
> Update: I'm now done with the first pass of this.
> I reversed all the programs and successfully ran them through my
> compiler (i haven't assembled or linked anything though).
> http://squoze.net/B/programs/
>
> To check for correctness, the files should of course be compiled,
> assembled and linked again. Unfortunately my compiler currently
> does not generate quite the same code as the original one. I will
> have to work on this.
> Most importantly & and | are only bitwise operators in the version
> of B that compiled these programs, but some other differences (like
> the fixup chain and the way strings are stored) exist too.
>
> It would be nice to have a fully working B system on v1/v2 UNIX again,
> with everything built from source, we can even reconstruct different
> versions of the runtime (and perhaps standard library). So far the
> PDP-11 version of my B system has only run on v6 and 2.11BSD.
>
> best,
> aap
>
> On 14/06/23, Angelo Papenhoff wrote:
>> I will hopefully continue with this in the next time (if, goto, mail and
>> glob are left).

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hi,

Sorry for my previous message, my analysis is wrong.

The return value is still a typo, but this expression should not pose a 
problem, the AST shows that the postinc has priority, uses a legit 
lvalue, which result is multiplied by zero.

This was probably not intended but syntactically correct.

I have added better error identification and now I see that my problem 
is in exp(s)

nextarg()[0] is refused.

because nextarg() is not a lvalue, as expected by the indexing operation.

I need to update my code generator so that any expression left of an 
index is accepted (and used as an address).

Sebastien


Le 19/06/2023 à 11:52, Sebastien F4GRX a écrit :
> Hello,
>
>
> my own compiler choked on if.b and mail.b because of this invalid 
> expression in nxtarg:
>
> if(ap>ac) return(0*ap++);
>
>
> I believe it should instead read:
>
> if(ap>ac) return 0;
>
>
> What do you think about this?
>
>
> PS: The original code gives this AST which shows how my compiler 
> interprets this source :
>
> function name nxtarg
> .  env: ref to function nxtarg
> .  env: ref to function main
> .  compound stmt
> .  .  env: extern ap
> .  .  env: extern ac
> .  .  env: extern argv
> .  .  env: ref to function nxtarg
> .  .  env: ref to function main
> .  .  if test
> .  .  .  operation: GT
> .  .  .  .  extern declaration ap
> .  .  .  .  extern declaration ac
> .  .  then stmt
> .  .  .  return stmt
> .  .  .  .  operation: MUL
> .  .  .  .  .  value: 0
> .  .  .  .  .  operation: POSTINC
> .  .  .  .  .  .  extern declaration ap
> .  .  return stmt
> .  .  .  [LVALUE] operation: INDEX
> .  .  .  .  extern declaration argv
> .  .  .  .  operation: POSTINC
> .  .  .  .  .  extern declaration ap
>
> Sebastien
>
>
> Le 17/06/2023 à 10:19, Angelo Papenhoff a écrit :
>> Update: I'm now done with the first pass of this.
>> I reversed all the programs and successfully ran them through my
>> compiler (i haven't assembled or linked anything though).
>> http://squoze.net/B/programs/
>>
>> To check for correctness, the files should of course be compiled,
>> assembled and linked again. Unfortunately my compiler currently
>> does not generate quite the same code as the original one. I will
>> have to work on this.
>> Most importantly & and | are only bitwise operators in the version
>> of B that compiled these programs, but some other differences (like
>> the fixup chain and the way strings are stored) exist too.
>>
>> It would be nice to have a fully working B system on v1/v2 UNIX again,
>> with everything built from source, we can even reconstruct different
>> versions of the runtime (and perhaps standard library). So far the
>> PDP-11 version of my B system has only run on v6 and 2.11BSD.
>>
>> best,
>> aap
>>
>> On 14/06/23, Angelo Papenhoff wrote:
>>> I will hopefully continue with this in the next time (if, goto, mail 
>>> and
>>> glob are left).

[TUHS] Re: Software written in B

[Lars Brinkhoff]

Sebastien F4GRX wrote:
>> my own compiler choked on if.b and mail.b because of this invalid
>> expression in nxtarg:
>>
>> if(ap>ac) return(0*ap++);
>
> The return value is still a typo, but this expression should not pose
> a problem, the AST shows that the postinc has priority, uses a legit 
> lvalue, which result is multiplied by zero.
>
> This was probably not intended but syntactically correct.

I could well believe it's not a typo, but a "clever" way to write

  if(ap>ac) {
    ap++;
    return 0;
  }

[TUHS] Re: Software written in B

[G. Branden Robinson]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

At 2023-06-19T10:48:27+0000, Lars Brinkhoff wrote:
> Sebastien F4GRX wrote:
> >> if(ap>ac) return(0*ap++);
> >
> > This was probably not intended but syntactically correct.
> 
> I could well believe it's not a typo, but a "clever" way to write
> 
>   if(ap>ac) {
>     ap++;
>     return 0;
>   }

/* You were not expected to understand that. */

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: Software written in B

[Sebastien F4GRX]

yeah, I see that's exactly right :-)

I lack a lot of context implied by these source codes. Compacity was 
quite important.

This is very interesting, and very useful to test my compiler, as I have 
guessed !

Sebastien


Le 19/06/2023 à 12:55, G. Branden Robinson a écrit :
> At 2023-06-19T10:48:27+0000, Lars Brinkhoff wrote:
>> Sebastien F4GRX wrote:
>>>> if(ap>ac) return(0*ap++);
>>> This was probably not intended but syntactically correct.
>> I could well believe it's not a typo, but a "clever" way to write
>>
>>    if(ap>ac) {
>>      ap++;
>>      return 0;
>>    }
> /* You were not expected to understand that. */
>
> Regards,
> Branden

[TUHS] Re: Software written in B

[segaloco via TUHS]

> This is very interesting, and very useful to test my compiler, as I have
> guessed !
> 
> Sebastien

That's wonderful news.  I'm glad I was able to point you in the right direction (and that I didn't have to reverse any B code with my luddite-level understanding of it...)

Team work makes the dream work!

- Matt G.

[TUHS] Re: Software written in B

[Angelo Papenhoff]

Another update: I have worked quite a bit on my compiler
the last couple of days and have managed to make it produce the same
code as those in the binaries (compared the intermediate code by eye).
There were a few mistakes, the files have been updated.

I removed some features that I figured were not in ken's original
compiler and most importantly changed it to generate RPN code directly
instead of parsing an expression into a tree and generating code from
that, which ken confirmed was how it worked.
I'm still not entirely happy with the result (the build() function seems
a bit kludgy), but at least it seems to produce something accurate.
Unfortunately I have no idea what the intermediate would have looked
like, so the output of this is purely my fantasy.
I will also have to adjust my take on ba now due to the changes.

For anyone interested, this is my WIP version of bc.b:
https://gist.github.com/aap/6df9b4c53c63592437d97dadab533649

aap

On 17/06/23, Angelo Papenhoff wrote:
> Update: I'm now done with the first pass of this.
> I reversed all the programs and successfully ran them through my
> compiler (i haven't assembled or linked anything though).
> http://squoze.net/B/programs/
> 
> To check for correctness, the files should of course be compiled,
> assembled and linked again. Unfortunately my compiler currently
> does not generate quite the same code as the original one. I will
> have to work on this.
> Most importantly & and | are only bitwise operators in the version
> of B that compiled these programs, but some other differences (like
> the fixup chain and the way strings are stored) exist too.
> 
> It would be nice to have a fully working B system on v1/v2 UNIX again,
> with everything built from source, we can even reconstruct different
> versions of the runtime (and perhaps standard library). So far the
> PDP-11 version of my B system has only run on v6 and 2.11BSD.
> 
> best,
> aap
> 
> On 14/06/23, Angelo Papenhoff wrote:
> > I will hopefully continue with this in the next time (if, goto, mail and
> > glob are left).

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hi,

Wow, this is amazing.

For my information, where are the initialization values for the 
ctab[128] vector coming from?

Do you still have the version that generates a tree before codegen?

I know that generating code while parsing is possible for stack based 
machines, this is also how Crenshaw describes it in its document (but 
for 68k).

I decided not to do it for my own compiler, so that I can write multiple 
code generators.

Sebastien

Le 23/06/2023 à 12:59, Angelo Papenhoff a écrit :
> Another update: I have worked quite a bit on my compiler
> the last couple of days and have managed to make it produce the same
> code as those in the binaries (compared the intermediate code by eye).
> There were a few mistakes, the files have been updated.
>
> I removed some features that I figured were not in ken's original
> compiler and most importantly changed it to generate RPN code directly
> instead of parsing an expression into a tree and generating code from
> that, which ken confirmed was how it worked.
> I'm still not entirely happy with the result (the build() function seems
> a bit kludgy), but at least it seems to produce something accurate.
> Unfortunately I have no idea what the intermediate would have looked
> like, so the output of this is purely my fantasy.
> I will also have to adjust my take on ba now due to the changes.
>
> For anyone interested, this is my WIP version of bc.b:
> https://gist.github.com/aap/6df9b4c53c63592437d97dadab533649
>
> aap
>
> On 17/06/23, Angelo Papenhoff wrote:
>> Update: I'm now done with the first pass of this.
>> I reversed all the programs and successfully ran them through my
>> compiler (i haven't assembled or linked anything though).
>> http://squoze.net/B/programs/
>>
>> To check for correctness, the files should of course be compiled,
>> assembled and linked again. Unfortunately my compiler currently
>> does not generate quite the same code as the original one. I will
>> have to work on this.
>> Most importantly & and | are only bitwise operators in the version
>> of B that compiled these programs, but some other differences (like
>> the fixup chain and the way strings are stored) exist too.
>>
>> It would be nice to have a fully working B system on v1/v2 UNIX again,
>> with everything built from source, we can even reconstruct different
>> versions of the runtime (and perhaps standard library). So far the
>> PDP-11 version of my B system has only run on v6 and 2.11BSD.
>>
>> best,
>> aap
>>
>> On 14/06/23, Angelo Papenhoff wrote:
>>> I will hopefully continue with this in the next time (if, goto, mail and
>>> glob are left).

[TUHS] Re: Software written in B

[Angelo Papenhoff]

On 23/06/23, Sebastien F4GRX wrote:
> For my information, where are the initialization values for the 
> ctab[128] vector coming from?

Probably some mix between last1120c and what made sense to me.
Actually found a bug in my compiler related to this, will have to check
my earlier (tree) compiler for this too.

> Do you still have the version that generates a tree before codegen?

https://github.com/aap/b/blob/master/bc.b

> I know that generating code while parsing is possible for stack based 
> machines, this is also how Crenshaw describes it in its document (but 
> for 68k).

What I found somewhat difficult and why i opted for the tree-approach
was mainly handling lvalues (but also conditional operators get a bit
easier).
If you have 'x = y', the compiler is supposed to generate
	va; 1	/ lval of x
	a; 2	/ rval of y
	b1	/ =
but when you pop the = it's already too late to change the 'a' to a
'va'. So my solution was to remember one operator of output so i can
combine it with the next one. I'm still not entirely happy with it (the
build() function especially), but it doesn't seem entirely wrong and
does generate matching B code.
Still, if people have suggestions how to do this better, I'd love to get
some feedback on this.


aap

[TUHS] Re: Software written in B

[Sebastien F4GRX]

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!

Thanks,

Sebastien

Le 23/06/2023 à 12:59, Angelo Papenhoff a écrit :
> Another update: I have worked quite a bit on my compiler
> the last couple of days and have managed to make it produce the same
> code as those in the binaries (compared the intermediate code by eye).
> There were a few mistakes, the files have been updated.
>
> I removed some features that I figured were not in ken's original
> compiler and most importantly changed it to generate RPN code directly
> instead of parsing an expression into a tree and generating code from
> that, which ken confirmed was how it worked.
> I'm still not entirely happy with the result (the build() function seems
> a bit kludgy), but at least it seems to produce something accurate.
> Unfortunately I have no idea what the intermediate would have looked
> like, so the output of this is purely my fantasy.
> I will also have to adjust my take on ba now due to the changes.
>
> For anyone interested, this is my WIP version of bc.b:
> https://gist.github.com/aap/6df9b4c53c63592437d97dadab533649
>
> aap
>
> On 17/06/23, Angelo Papenhoff wrote:
>> Update: I'm now done with the first pass of this.
>> I reversed all the programs and successfully ran them through my
>> compiler (i haven't assembled or linked anything though).
>> http://squoze.net/B/programs/
>>
>> To check for correctness, the files should of course be compiled,
>> assembled and linked again. Unfortunately my compiler currently
>> does not generate quite the same code as the original one. I will
>> have to work on this.
>> Most importantly & and | are only bitwise operators in the version
>> of B that compiled these programs, but some other differences (like
>> the fixup chain and the way strings are stored) exist too.
>>
>> It would be nice to have a fully working B system on v1/v2 UNIX again,
>> with everything built from source, we can even reconstruct different
>> versions of the runtime (and perhaps standard library). So far the
>> PDP-11 version of my B system has only run on v6 and 2.11BSD.
>>
>> best,
>> aap
>>
>> On 14/06/23, Angelo Papenhoff wrote:
>>> I will hopefully continue with this in the next time (if, goto, mail and
>>> glob are left).

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hello,

Yes, I found your code.

Le 23/06/2023 à 16:01, Angelo Papenhoff a écrit :
> Probably some mix between last1120c and what made sense to me.
> Actually found a bug in my compiler related to this, will have to check
> my earlier (tree) compiler for this too.

It looks like these definitions are in 
https://github.com/aap/b/blob/master/b.h

Do you pre-process your B source files?

Sebastien

[TUHS] Re: Software written in B

[Angelo Papenhoff]

This is for the compiler i wrote in C, for bootstrapping.
I do use symbolic constants in the B code too, but there i'm just
using sed as a preprocessor.

On 23/06/23, Sebastien F4GRX wrote:
> It looks like these definitions are in 
> https://github.com/aap/b/blob/master/b.h
> 
> Do you pre-process your B source files?
> 
> Sebastien
> 

[TUHS] Re: Software written in B

[Angelo Papenhoff]

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:
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/ind.b#L3

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.

aap


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!

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Hi,

I just modified my compiler to support both syntaxes, that was easy. I 
am not trying to make my compiler as small as possible.

The 6070 version also has "default:" in the switch statement and "break" 
to exit compound statements, of which I have just implemented the second 
for now. Thats completely backwards compatible with the early version. 
These are just fancy goto and labels.

The ind.b program you shared must have been even earlier, using $( $) 
instead of braces and no parentheses on function names. With the price 
of storage these guys were really minimalists! I can imagine Ken not 
being happy about empty parentheses for functions without parameters :-)

Would you mind to share your sed script to preprocess your B B compiler? 
Thats the only thing missing for me to try compiling it.

Sebastien


Le 23/06/2023 à 16:49, Angelo Papenhoff a écrit :
> 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:
> https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/ind.b#L3
>
> 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.
>
> aap
>
>
> 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!

[TUHS] Re: Software written in B

[Angelo Papenhoff]

On 23/06/23, Sebastien F4GRX wrote:
> Would you mind to share your sed script to preprocess your B B compiler? 
> Thats the only thing missing for me to try compiling it.

Still same as my original compiler, so e.g.
https://github.com/aap/b/blob/master/pdp11/preproc.sh
Only the first few lines are platform dependent.


aap

[TUHS] Re: Software written in B

[Sebastien F4GRX]

Thanks, I missed that one.

My test driver program is now able to apply this preprocessing before 
running the compiler, but I forgot to implement parsing of global vector 
initializers, so i have to do that before :-)

Sebastien

Le 23/06/2023 à 17:36, Angelo Papenhoff a écrit :
> On 23/06/23, Sebastien F4GRX wrote:
>> Would you mind to share your sed script to preprocess your B B compiler?
>> Thats the only thing missing for me to try compiling it.
> Still same as my original compiler, so e.g.
> https://github.com/aap/b/blob/master/pdp11/preproc.sh
> Only the first few lines are platform dependent.
>
>
> aap