[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Noel Chiappa]

    > From: Al Kossow 

    > What was the name of the system(s)?

From an early 'hosts' file:

  HOST MIT-RTS,           [CHAOS 470,LCS 10/11],SERVER,UNIX,PDP11,[RTS,DSSR]

I'd rather depend on that, than on my memory! (The names at the end are
aliases.)


While I was looking for a really early host file (I recall our early TFTP
command had one; I don't think it was built into the command, but it might
have been),~p
 I found a /jnk directory in MIT-CSR's root; it had a lot of
interesting stuff in it. One particularly interesting one was 'kov':

  The idea of this kernel overlay scheme is to increase the amount of code
  that can be included in the UNIX kernel. This is done by reserving one of
  the I space segmentation registers (the highest free, usually KISA5 for
  non-split systems) and changing its value dynamically so as to map in the
  appropriate code as needed. I chose to use only one page register (limiting
  each KOV to 4Kw), in order to minimize the mapping overhead.

I wonder if this is an early predecessor to the overlay stuff in BSD 2.9 (and
later BSD's)? That stuff is all poorly documented, and I'm not up for poring
through both to compare them. This one was all done by Ken Harrenstien (KLH).

	Noel

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Clem Cole]

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

On Mon, May 12, 2025 at 12:21 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>
> I wonder if this is an early predecessor to the overlay stuff in BSD 2.9
> (and
> later BSD's)?
>
Unlikely.   The BSD overlay stuff was based on Fred Cantor work at DEC in
the TIG group in Merrimack, NH that did V7m and later Ultrix11.
Fred's code works on 11/40 as well as 11/45 class processors, where as by
the time of 2.11BSD they dropped the 11/40 support.
ᐧ

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

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Lars Brinkhoff]

arnold@skeeve.com wrote:
> Any chance that the Mt. Xinu 4.3 BSD + NFS distribution tapes
> are in there?

Sorry, I really can't say.

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Sebastien F4GRX]

Hello,

On 12/05/2025 10:10, Thalia Archibald via TUHS wrote:
> I just watched your talk. Now the B intermediate language makes a lot more sense
> and I want to write a B compiler :).

I did that, it was fun. I did a recursive descent parser (from scratch, 
so without yacc), and made it generate some C code.

 From a practical aspect, having tasted C for years, I find B quite 
annoying and pointless outside the gigantic historical interest.

Sebastien

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[arnold]

Any chance that the Mt. Xinu 4.3 BSD + NFS distribution tapes
are in there?

Arnold

Lars Brinkhoff <lars@nocrew.org> wrote:

> Noel Chiappa writes:
> > And I should ask Lars if the backup tapes of the DSSR/RTS machine went
> > to the MIT archives - they might well have done, and Prof. Ward just
> > didn't know that.
>
> They might.  There are thousands of tapes, most of which are from ITS or
> TOPS-20.  But that still leaves room for hundreds of Unix tar, dump, and
> cpio tapes in various interesting 16/32-bit and big/little endian
> combinations.  I'm guessing they are 4BSD, Sun, and maybe PDP-11
> formats.  I haven't taken the time to go through them; in many cases
> modern tools don't work, so I have to make my own.
>
> A propos Teixeira's message, there are also VMS tapes with NIL.

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Tom Teixeira]

On 5/12/25 9:42 AM, Al Kossow wrote:
> On 5/12/25 6:38 AM, Lars Brinkhoff wrote:
>> Noel Chiappa writes:
>>> And I should ask Lars if the backup tapes of the DSSR/RTS machine went
>>> to the MIT archives - they might well have done, and Prof. Ward just
>>> didn't know that.
>>
>
> What was the name of the system(s)?
>
> A complication is MIT, being MIT, used their own backup tape format
> on some of their Unix systems.
>
Delphi was the home-written time-sharing system for the PDP-11/45 I 
referred to. It would have had some home-written backup tape format. I'm 
not sure if it was backed up to tape, or just to duplicate RK05 packs. 
In addition to Steve Ward, Chris Terman may remember something about the 
Delphi system and backups.

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Al Kossow]

On 5/12/25 6:38 AM, Lars Brinkhoff wrote:
> Noel Chiappa writes:
>> And I should ask Lars if the backup tapes of the DSSR/RTS machine went
>> to the MIT archives - they might well have done, and Prof. Ward just
>> didn't know that.
> 

What was the name of the system(s)?

A complication is MIT, being MIT, used their own backup tape format
on some of their Unix systems.

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Lars Brinkhoff]

Noel Chiappa writes:
> And I should ask Lars if the backup tapes of the DSSR/RTS machine went
> to the MIT archives - they might well have done, and Prof. Ward just
> didn't know that.

They might.  There are thousands of tapes, most of which are from ITS or
TOPS-20.  But that still leaves room for hundreds of Unix tar, dump, and
cpio tapes in various interesting 16/32-bit and big/little endian
combinations.  I'm guessing they are 4BSD, Sun, and maybe PDP-11
formats.  I haven't taken the time to go through them; in many cases
modern tools don't work, so I have to make my own.

A propos Teixeira's message, there are also VMS tapes with NIL.

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Noel Chiappa]

    > From: Tom Teixeira

    > before the RTS group at Project MAC

(Called the DSSR group at that point om time, if anyone wants to look
anything up.)

    > I got a BCPL compiler from somewhere and made some enhancements - such
    > as direct support for external variables and routines using a linker
    > rather than the pure BCPL global array.

This entire toolchain, including all the source, has been preserved; the BCPL
compiler, the linker ('bind', itself written in BCPL), and a number of tools
(including an extra one, 'ldrel', written by the CSR group on the 5th floor).
I have in the past put up some pieces for download, but I never got around to
doing the whole thing, as there didn't seem to be any interest.

We (CSR) started working with the toolchain because it included support for
MACRO-11 (the BCPL compiler could produce either MACRO-11 or UNIX assembler
source as output). That toolchain used a relocatable formet, .rel':

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/man5/rel.5

that I think was based on one DEC had done.

CSR was working with a semi-real-time operating system, called 'MOS':

  https://gunkies.org/wiki/MOS_operating_system

for the PDP-11, that we'd gotten from SRI. (MOS was used a lot in early work
on the Internet; e.g. all the BBN 'core' routers used in the early Internet
used it, after the very first ones [written in BCPL, oddly enough], which had
used ELF:

  https://gunkies.org/wiki/ELF_operating_system

but BBN soon switched to MOS.) MOS was written in MACRO-11; we started
working with MOS with the same toolchain SRI had used for it, which ran on
TOPS-20. I soon decided I'd rather work on our group's PDP-11, initially a
PDP-11/40 running a clone of the DSSR system (the first UNIX at MIT). So,
we started working with the MACRO-11, and bind, on UNIX.

I then decided I'd rather write code for our PDP-11 packet switches in this
nifty language called C, used on UNIX, which nobody else knew about (at that
point). The first step was to write 'ldrel', to convert a.out files (produced
by the C compiler) to .rel files, so 'bind' could work with them.

After a while, we decided we'd rather use 'ld' as our linker (I think because
it supported demand loading from binary libraries, so we didn't have to
manually specify every file to link). The DSSR group had long ago written
'relld', which converted .rel files (produced by MACRO-11) to a.out files, so
that was pretty easy.


There seems to be a version of the BCPL compiler which produces 8080 code.

It looks like that pre-dates the 8086 C compiler from MIT (the 8080 C
compiler was not done at MIT).

(I just ran across a 6502 emulator written by Rae McLellan of DSSR; he and
they seem to have done a lot of work with various micros. It may not have all
the pieces it needs to work, though; it seems to need
"/usr/simulators/s6502/s6502.body" from the DSSR machine.)

Pity I didn't save a dump of that machine too; I was once looking for the
source of the Algol interpreter, written on the Delphi machine, and made to
run under UNIX, and I asked Steve Ward if any dumps of the DSSR/RTS machine
still existed, and he thought not. So we have the binary of that Algol
interpreter, but not the source. Of course, it was probably written in
MACRO-11, so a disassembler would produce a reasonable facsimile.

And I should ask Lars if the backup tapes of the DSSR/RTS machine went to the
MIT archives - they might well have done, and Prof. Ward just didn't know
that.

	Noel

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Thalia Archibald via TUHS]

On May 12, 2025, at 00:14, Angelo Papenhoff wrote:
> thanks for mentioning my project!
> I recently ported the compiler to ITS on the PDP-10 and had to revisit
> the question of the intermediate code.
> My take is that it was probably an ASCII code and not all too different
> from PDP-7 assembly.

Very interesting! Is your take on the intermediate code the cases in
pdp10_its/ba10.b:cexpr?

In your compilers, you hack in preprocessing with sed. Do you know for sure that
B had no preprocessor? It seems inconceivable now, as even `as` had constants.

> You may also want to check out my talk on B at VCFB 2024:
> https://www.youtube.com/watch?v=OLDTPlLa1bI

I just watched your talk. Now the B intermediate language makes a lot more sense
and I want to write a B compiler :).

Have you done any further archaeology work on NB since what you have at
<http://squoze.net/NB/>? How did you analyze the old tapes? Is there anything
left there to examine?

Thalia

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Angelo Papenhoff]

Hi,
thanks for mentioning my project!
I recently ported the compiler to ITS on the PDP-10 and had to revisit
the question of the intermediate code.
My take is that it was probably an ASCII code and not all too different
from PDP-7 assembly. One striking difference between the PDP-7 and
PDP-11 interpreter that have survived is the handling of lvalues. Taking
the address of something is done by an operator (u1) in the PDP-7
interpreter, whereas on the PDP-11 this is handled somewhere in the
compilation process, and in addition to the automatic (a) and external
(x) operators there are now lvalue versions of them (va and vx).
I very very strongly suspect that this is handled by the B assembler and
not the compiler.

Two other questions are where the 'i'-versions of the a/x/c operators
and the control flow of the conditional ?: operator were handled.
For the latter i concluded it had to be the assembler, although the
label numbers in printf.o are in line with those that would have been
generated by the compiler. In contrast, the first and second pass of
the C compiler use different ranges of labels.

Unfortunately all these questions appeared and became clearer only over time
and as a result there are various incarnations of my reconstructed compiler
in the github repo....I should really make a push to clean it up a bit
better, it's a complete mess.

You may also want to check out my talk on B at VCFB 2024:
https://www.youtube.com/watch?v=OLDTPlLa1bI

Cheers,
aap

On 12/05/25, Thalia Archibald via TUHS wrote:
> On May 11, 2025, at 03:28, Jackson Helie G wrote:
> > I am curious about what the intermediate code generated by bc is?
> 
> 
> Hi,
> 
> I don’t have a direct answer, but I can refer you to Angelo Papenhoff’s work in
> reconstructing B, which is probably the most extensive and faithful to the
> original. He’s written B compilers[0] in C for bootstrapping purposes, another
> in B, and reconstructed one in B which works on Unix V1. The intermediate code I
> think you’re referring to is the threaded code, which Angelo covers on his
> site[1], from having reverse engineered libb and bilib. There was some
> discussion on this list about it some years ago[2]. His work is probably the
> best resource.
> 
> [0]: https://github.com/aap/b
> [1]: http://squoze.net/B/
> [2]: https://www.tuhs.org/pipermail/tuhs/2019-April/017750.html
> 
> Thalia

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Thalia Archibald via TUHS]

On May 11, 2025, at 03:28, Jackson Helie G wrote:
> I am curious about what the intermediate code generated by bc is?


Hi,

I don’t have a direct answer, but I can refer you to Angelo Papenhoff’s work in
reconstructing B, which is probably the most extensive and faithful to the
original. He’s written B compilers[0] in C for bootstrapping purposes, another
in B, and reconstructed one in B which works on Unix V1. The intermediate code I
think you’re referring to is the threaded code, which Angelo covers on his
site[1], from having reverse engineered libb and bilib. There was some
discussion on this list about it some years ago[2]. His work is probably the
best resource.

[0]: https://github.com/aap/b
[1]: http://squoze.net/B/
[2]: https://www.tuhs.org/pipermail/tuhs/2019-April/017750.html

Thalia

[TUHS] Re: What is the intermediate code generated by the bc interpreter?

[Tom Teixeira]

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

On 5/11/25 6:28 AM, Jackson Helie G wrote:
> I checked Dennis M. Ritchie's "Users' Reference to B" and found an 
> example of implementing a B program at the bottom of the manual. It 
> said that bc generates intermediate code suitable for ba, and then ba 
> generates assembly code. So, I am curious about what the intermediate 
> code generated by bc is?

I found this reference 
(https://www.softwarepreservation.org/projects/BCPL/cambridge/Richards-Bootstrapping_BCPL-1973.pdf) 
written by Martin Richards about the intermediate code of BCPL. I never 
saw or used B, but this is one possibility.

But it seems very different from C compilers prior to the Portable C 
Compiler, even though code generation was table driven 
(https://wolfram.schneider.org/bsd/7thEdManVol2/ctour/ctour.html).

Note, before the RTS group at Project MAC started using UNIX, we had a 
home-written operating system for PDP-11/45 and PDP-11/70. I got a BCPL 
compiler from somewhere and made some enhancements - such as direct 
support for external variables and routines using a linker rather than 
the pure BCPL global array. When RTS got access to a VAX-11/780 running 
VMS, I was able to modify the Sixth or Seventh edition C compiler to 
generate code for the VAX-11/780 and wrote enough of a compatibility 
library to port various C programs to VMS. All that vanished once we 
were able to install 4BSD on the VAX-11/780. The machine was shared by 
the people doing the NIL project (New Implementation of LISP) on the 
VAX. I don't remember the details, but this paper coauthored by Guy 
Steele (https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf) implies that 
NIL shifted their efforts to a different target machine: "In 1978, 
Gabriel and Guy Steele set out to implement NIL [Brooks, 1982a] on the 
S-1 Mark IIA, a supercomputer being designed and built by the Lawrence 
Livermore National Laboratory [Correll, 1979; Hailpern, 1979]."

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