7 Jun
2023
7 Jun
'23
10:14 a.m.
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)
7 Jun
7 Jun
10:38 a.m.
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
3:05 p.m.
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)
3:57 p.m.
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(a)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)
4:21 p.m.
Clem Cole <clemc(a)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!
5:26 p.m.
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(a)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
6:16 p.m.
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.
11:49 p.m.
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.
8 Jun
8 Jun
2:10 a.m.
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
3:31 a.m.
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.
2:41 p.m.
Andrew Hume <andrew(a)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
3:05 p.m.
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.
9 Jun
9 Jun
8:56 a.m.
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)
9:57 a.m.
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
14 Jun
14 Jun
11:51 a.m.
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.
8:03 p.m.
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
9:53 p.m.
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(a)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
10:05 p.m.
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(a)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
15 Jun
15 Jun
8 a.m.
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
8:21 a.m.
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
8:33 a.m.
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
17 Jun
17 Jun
8:19 a.m.
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).
19 Jun
19 Jun
9:52 a.m.
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).
10:18 a.m.
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).
10:48 a.m.
Sebastien F4GRX wrote:
I could well believe it's not a typo, but a "clever" way to write
if(ap>ac) {
ap++;
return 0;
}
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. 
10:55 a.m.
At 2023-06-19T10:48:27+0000, Lars Brinkhoff wrote:
Sebastien F4GRX wrote:
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
if(ap>ac) return(0*ap++);
This was probably not intended but syntactically correct.
11:07 a.m.
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:
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
if(ap>ac) return(0*ap++);
This was probably not intended but syntactically correct.
6:44 p.m.
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.
23 Jun
23 Jun
10:59 a.m.
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).
1:32 p.m.
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).
2:01 p.m.
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
2:10 p.m.
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).
2:14 p.m.
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
2:39 p.m.
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
2:49 p.m.
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!
3:31 p.m.
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!
3:36 p.m.
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
3:53 p.m.
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
314
days inactive
330
days old
37 comments
10 participants
participants (10)
-
Andrew Hume -
Angelo Papenhoff -
arnold＠skeeve.com -
Bakul Shah -
Clem Cole -
G. Branden Robinson -
Lars Brinkhoff -
Phil Budne -
Sebastien F4GRX -
segaloco