Hello,

I'm trying to get TENEX to run on a PDP-10 emulator. Before I go off
into the weeds, has anyone else done this in modern times?

This is the material I have to work with:
http://www.bitsavers.org/bits/BBN/Tenex/
http://www.bitsavers.org/pdf/bbn/tenex/
https://github.com/PDP-10/tenex

The Monitor manual describes how to build a fresh system from scratch,
so I think the project should be feasible. Any other hints, ideas,
warnings, etc would be appreciated.

Best regards,
Lars Brinkhoff

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> I'm trying to get TENEX to run on a PDP-10 emulator. Before I go off
> into the weeds, has anyone else done this in modern times?

> This is the material I have to work with:
> http://www.bitsavers.org/bits/BBN/Tenex/
> http://www.bitsavers.org/pdf/bbn/tenex/
> https://github.com/PDP-10/tenex

> The Monitor manual describes how to build a fresh system from scratch,
> so I think the project should be feasible. Any other hints, ideas,
> warnings, etc would be appreciated.

Hi, Lars! I haven't kept up with Rich's emulators. Does he emulate the BBN
paper somewhere? Or are you going to build this for the KI-10 al al DEC?

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson wrote:
> Hi, Lars! I haven't kept up with Rich's emulators. Does he emulate
> the BBN pa[g]er somewhere?

Yes he does. And it's used by WAITS, so it has seen some testing.

> Or are you going to build this for the KI-10 al al DEC?

KA10 would be the main target, but hopefully KI10 too:
https://github.com/PDP-10/tenex/blob/master/133-tenex/kisrv.mac

Hello,

Some TENEX source files use ".DIRECTIVE XSRCVN FOO", where FOO is a
symbol name. According to comments it should set the vaule of FOO to
the source file version number. I searched around, but I didn't find
any version of MACRO with support for this.

I did see this, so apparently someone else encountered this problem
before:
REPEAT 0,<.DIRECTIVE XSRCVN SRCVNO> ; DEC MACRO doesn't support this

Maybe it's a BBN addition to MACRO. Does anyone have a copy?

On Thursday, March 24, 2022 at 10:55:03 PM UTC-7, lars...@nocrew.org wrote:
> Some TENEX source files use ".DIRECTIVE XSRCVN FOO", where FOO is a
> symbol name. According to comments it should set the vaule of FOO to
> the source file version number. I searched around, but I didn't find
> any version of MACRO with support for this.

Reminds me how CVS will substitute version numbers and dates
in files, with special symbols that it recognizes.

Where does the version number come from? That should help find
who puts it in.

gah4 wrote:
> Where does the version number come from? That should help find
> who puts it in.

I suppose it must either come from the file name on the command line, or
a JSYS providing the information from an open JFN. In either case, it
would most likely be a modified version of MACRO doing this.

gah4 <gah4@u.washington.edu> writes:
>On Thursday, March 24, 2022 at 10:55:03 PM UTC-7, lars...@nocrew.org wrote:
>
>> Some TENEX source files use ".DIRECTIVE XSRCVN FOO", where FOO is a
>> symbol name. According to comments it should set the vaule of FOO to
>> the source file version number. I searched around, but I didn't find
>> any version of MACRO with support for this.
>
>Reminds me how CVS will substitute version numbers and dates
>in files, with special symbols that it recognizes.

For what it is worth, CVS uses RCS under the covers, and
RCS got the idea from SCCS...

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> gah4 wrote:

>> Where does the version number come from? That should help find
>> who puts it in.

> I suppose it must either come from the file name on the command line, or
> a JSYS providing the information from an open JFN. In either case, it
> would most likely be a modified version of MACRO doing this.

This is a TENEX extension to Macro-10, which was until very very recently a
Tops-10 program which ran under the compatibility package PA1050 on TENEX and
TOPS-20. No publicly available version of Macro-10 uses JSYS calls natively,
only invokes them via the compatibility in order to emulate the older Tops-10
UUOs.

Tops-10 has no concept of file versioning, only *program* versioning (which is
part of the program address space, in location .JBVER = 137, where the standard
start location for program text is .JBDA = 140 unless otherwise arranged for in
the course of assembly/linkage).

TENEX defined a file name as being made up of 3 parts: The name (6 SIXBIT
characters), the extension (3 SIXBIT characters), and the generation (an 18 bit
number). This generation number is often referred to as the "source version"
number.

Presumably, this directive causes code in Macro-10 to obtain the source file
generation number via a call into the compatibility package and assign it to a
symbol in the program symbol table which is being built.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson wrote:
> TENEX defined a file name as being made up of 3 parts: The name (6
> SIXBIT characters), the extension (3 SIXBIT characters)

This surprised me, as I thought TENEX allowed longer file names.
https://opost.com/tenex/fjcc72/ says names can be up to 39 characters.

> Presumably, this directive causes code in Macro-10 to obtain the
> source file generation number via a call into the compatibility
> package and assign it to a symbol in the program symbol table which is
> being built.

I think you're right about this. Unfortunately this extension seems
lost. As luck would have it, other versions of TENEX doesn't use the
directive, and the one that does seems to not refer to the XSRCVN
information elsewhere.

I have found a 28-MAR-74 "BBN - TENEX VERSION" of MACRO, and an even
more recent 21-MAY-75 version with ;FIXES TO MAKE IT TENEX COMPATABLE.
Even though they don't have the XSRCVN directive I hope they will have
other things needed to asssemble TENEX.

TENEX sharable save file format. Reverse engineered from the GET JSYS
in SWPMON.MAC.

The file format consists of three sections:

1. Page map, which is two pages.
2. Data pages.
3. Symbol table.

All pages are 512 (decimal) words.

PAGE MAP

The first word in the page map has 001000 in the left half, and a count
in the right half.

Then follow "count" page map words:

| 0-8 | 9-17 | 18-35 |
| Access | Memory page | File page |

Page numbers, both virtual and file, are normally ordered by increasing
number. File pages start at 2. Pages which are unmapped (or all zero?)
are not written to the map or data pages.

Access bits:

0 - Write copy request - sets copy on write bit (9)
2 - Read allowed
3 - Write allowed
4 - Execute allowed
8 - Trap to user

Bit 0 is moved to bit 9 in the access bits which is then passed to the
PMAP JSYS in AC3.

Finally follows a start instruction.

The remaining space in this section is unused and should be zero.

DATA PAGES

Data pages follow and are mapped as per above. The section ends with the
highest numbered file page in the map.

SYMBOL TABLE

After the last mapped page comes a symbol table, which is alternating
words of SQUOZE symbol name and 36-bit symbol value.

On Saturday, March 26, 2022 at 6:05:05 AM UTC-7, lars...@nocrew.org wrote:

(snip)

> I have found a 28-MAR-74 "BBN - TENEX VERSION" of MACRO, and an even
> more recent 21-MAY-75 version with ;FIXES TO MAKE IT TENEX COMPATABLE.
> Even though they don't have the XSRCVN directive I hope they will have
> other things needed to asssemble TENEX.

Favorite way to write assembly code for new processors (mostly 8 bit
microprocessors) in the 1970's was to write macros for some other macro
assembler, that would generate the appropriate bits.

The assembler would then generate its normal object code, which would then
be post-processed to generate the desired form. Also, post-process the printer
output file to make it look right.

The easy fix for XSRCVN is to preprocess the source, to make it look like the
assembler (without the special feature) expects. I would not be surprised
if that is what people in the 1970's would have done.

gah4 <gah4@u.washington.edu> writes:

> Favorite way to write assembly code for new processors (mostly 8 bit
> microprocessors) in the 1970's was to write macros for some other macro
> assembler, that would generate the appropriate bits.

> The assembler would then generate its normal object code, which would then
> be post-processed to generate the desired form. Also, post-process the printer
> output file to make it look right.

> The easy fix for XSRCVN is to preprocess the source, to make it look like the
> assembler (without the special feature) expects. I would not be surprised
> if that is what people in the 1970's would have done.

That has nothing to do with the XSRCVN directive, which is a TENEX specific mod
to Macro-10 to do a TENEX specific job on the same architecture that Tops-10
runs on.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Thursday, March 31, 2022 at 2:13:41 PM UTC-7, Rich Alderson wrote:
> gah4 <ga...@u.washington.edu> writes:
> > Favorite way to write assembly code for new processors (mostly 8 bit
> > microprocessors) in the 1970's was to write macros for some other macro
> > assembler, that would generate the appropriate bits.
> > The assembler would then generate its normal object code, which would then
> > be post-processed to generate the desired form. Also, post-process the printer
> > output file to make it look right.
> > The easy fix for XSRCVN is to preprocess the source, to make it look like the
> > assembler (without the special feature) expects. I would not be surprised
> > if that is what people in the 1970's would have done.

> That has nothing to do with the XSRCVN directive, which is a TENEX specific mod
> to Macro-10 to do a TENEX specific job on the same architecture that Tops-10
> runs on.

Which has nothing to do with which?

The idea of preprocessing input to, or post-processing output from,
language processor is not new, and has been done in many
different ways.

I suspect you are right, that it was a specially modified assembler.
Even so, I wouldn't be surprised if preprocessing was used before the
modified assembler was available.

Is the TENEX object program format the same as other PDP-10 systems?

gah4 wrote:
> Is the TENEX object program format the same as other PDP-10 systems?

It's not. A TENEX .SAV file can be either the TOPS-10 compressed save
file format, or a sharable format that is distinct from a TOPS-20 .EXE:

I decoded the file format from monitor code:
https://github.com/PDP-10/tenex/wiki/Sharable-SAVE-file-format

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> gah4 wrote:

>> Is the TENEX object program format the same as other PDP-10 systems?

Yes. Macro-10, whether on Tops-10 or on TENEX/TOPS-20 under PA1050, generates
the same .REL file for the same source.

> It's not. A TENEX .SAV file can be either the TOPS-10 compressed save
> file format, or a sharable format that is distinct from a TOPS-20 .EXE:

An executable =/= an object file: The latter has to have relocatable objects
addresses resolved in order to create the latter.

NB: I am intimately familiar with the internals of Macro-10 and PA1050.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson wrotel
> An executable =/= an object file: The latter has to have relocatable
> objects addresses resolved in order to create the latter.

Point taken. I was assuming gah4 was asking about executables.

>>> Is the TENEX object program format the same as other PDP-10 systems?
> Yes. Macro-10, whether on Tops-10 or on TENEX/TOPS-20 under PA1050,
> generates the same .REL file for the same source.

The versions of MACRO, LOADER, and LINK that are distributes with TENEX
have many assembler conditionals for TENEX. I haven't checked exactly
what they do, but assembling monitor sources seem to work better with
"TENEX MACRO" rather than a contemporary DEC MACRO. I have yet to see
what happens at the loading stage.

Are you 100% sure that .REL as used on TENEX is exactly the same as on
TOPS-10/20? If so, that would be valuable information.

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> Are you 100% sure that .REL as used on TENEX is exactly the same as on
> TOPS-10/20? If so, that would be valuable information.

Let's say that I'm 99% certain that the internal layout of a .REL file is the
same on Tops-10 and TENEX. Point me at a TENEX .REL file and I'll do the
research to verify that last 1%.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

Rich Alderson wrote:
> Let's say that I'm 99% certain that the internal layout of a .REL file
> is the same on Tops-10 and TENEX. Point me at a TENEX .REL file and
> I'll do the research to verify that last 1%.

Thank you! I have emailed a DUMPER tape with some .REL files assembled
by the patched MACRO.

On Saturday, April 2, 2022 at 6:10:14 PM UTC-7, Rich Alderson wrote:

(snip)

> Let's say that I'm 99% certain that the internal layout of a .REL file is the
> same on Tops-10 and TENEX. Point me at a TENEX .REL file and I'll do the
> research to verify that last 1%.
I suppose that works for features that those files use ...

Reminds me that the OS/360 (and still in use) object file format
allows for relocation factors of -1, 0, 1, and 2. I can figure
out how to write one with -1 or 2, but have never seen that in
an actual program. I suspect you could look at a very large
number of files, and not find out that existed.

As well as I know, no other object file format allows for it.

On 2022-04-07 15:51, gah4 wrote:
> On Saturday, April 2, 2022 at 6:10:14 PM UTC-7, Rich Alderson wrote:
>
> (snip)
>
>> Let's say that I'm 99% certain that the internal layout of a .REL file is the
>> same on Tops-10 and TENEX. Point me at a TENEX .REL file and I'll do the
>> research to verify that last 1%.
>
> I suppose that works for features that those files use ...
>
> Reminds me that the OS/360 (and still in use) object file format
> allows for relocation factors of -1, 0, 1, and 2. I can figure
> out how to write one with -1 or 2, but have never seen that in
> an actual program. I suspect you could look at a very large
> number of files, and not find out that existed.
>
> As well as I know, no other object file format allows for it.

I don't even know what that means. :-)

The object file formats I know about allows for individual symbols to be
referenced, and even used in various complex expressions in the object
file, without knowing the value of the symbol. All resolved at linking time.

But what would that -1, 0, 1 or 2 relocation factor be about?

Johnny

Johnny Billquist writes:
> But what would that -1, 0, 1 or 2 relocation factor be about?

I imagine it's a multiplier for program execution speed.

On Friday, April 8, 2022 at 8:55:32 AM UTC-7, Johnny Billquist wrote:

(snip, I wrote)

> > Reminds me that the OS/360 (and still in use) object file format
> > allows for relocation factors of -1, 0, 1, and 2. I can figure
> > out how to write one with -1 or 2, but have never seen that in
> > an actual program. I suspect you could look at a very large
> > number of files, and not find out that existed.

> > As well as I know, no other object file format allows for it.
> I don't even know what that means. :-)
> The object file formats I know about allows for individual symbols to be
> referenced, and even used in various complex expressions in the object
> file, without knowing the value of the symbol. All resolved at linking time.

For usual assemblers, symbols are either absolute (don't change with
the address of the module) or relocatable (do change). Absolute
addresses have relocation factor 0.

The assembler starts (usually) at address zero for each object file.
When it is linked, the linker gives it a different starting address, and
adds that to all the relocatable addresses (with relocation factor 1).

If your "various complex expression" adds two relocatable values,
then the linker has to add twice the offset. If you negate a
relocatable value, the linker has to subtract the offset,
instead of adding. Most linkers don't do that, and so the
assembler has no way to ask for it to be done.

> But what would that -1, 0, 1 or 2 relocation factor be about?

On Thursday, April 7, 2022 at 6:51:26 AM UTC-7, gah4 wrote:

(snip)

> Reminds me that the OS/360 (and still in use) object file format
> allows for relocation factors of -1, 0, 1, and 2. I can figure
> out how to write one with -1 or 2, but have never seen that in
> an actual program. I suspect you could look at a very large
> number of files, and not find out that existed.

It seems that the PDP-10 has a more complicated system for
handling other than normal relocation, which is called Polish.
(Calculator users might call it Forward Polish Notation.)

It looks like Macro-10 puts an apostrophe after a relocatable
address in the assembly listing.

The assembler supplies a program for the linker to calculate
the relocated value. And I suspect that, like the unusual cases
for OS/360, it is not commonly used.

In any case, as with any rarely used feature, it isn't easy to get
tested well, and also not easy to find instance of its use.

On 2022-04-08 20:47, gah4 wrote:
> On Friday, April 8, 2022 at 8:55:32 AM UTC-7, Johnny Billquist wrote:
>
> (snip, I wrote)
>
>>> Reminds me that the OS/360 (and still in use) object file format
>>> allows for relocation factors of -1, 0, 1, and 2. I can figure
>>> out how to write one with -1 or 2, but have never seen that in
>>> an actual program. I suspect you could look at a very large
>>> number of files, and not find out that existed.
>
>>> As well as I know, no other object file format allows for it.
>> I don't even know what that means. :-)
>
>> The object file formats I know about allows for individual symbols to be
>> referenced, and even used in various complex expressions in the object
>> file, without knowing the value of the symbol. All resolved at linking time.
>
> For usual assemblers, symbols are either absolute (don't change with
> the address of the module) or relocatable (do change). Absolute
> addresses have relocation factor 0.
>
> The assembler starts (usually) at address zero for each object file.
> When it is linked, the linker gives it a different starting address, and
> adds that to all the relocatable addresses (with relocation factor 1).
>
> If your "various complex expression" adds two relocatable values,
> then the linker has to add twice the offset. If you negate a
> relocatable value, the linker has to subtract the offset,
> instead of adding. Most linkers don't do that, and so the
> assembler has no way to ask for it to be done.

Oh. Well, in that case, the object file format for DEC PDP-11 OSes are
way more advanced.

Relative references can have two or more relative symbols or values, and
you can do: addition, subtraction, multiplication, division, logical
and, logical or, negate, complement. And you can pretty much do an
arbitrary number of these operations for one value. (There are actually
a couple of more things it can do as well, but it's complicated to
describe it all in a simple way.)

And it's all simple to express in the assembler as well. A simple
expression like:

MOV #A+B-G1/<G2&<^C177120!G3>>,R1

where all symbols are relative addresses or other unknown values is
perfectly legal.
This example actually came out of the task builder manual for RSX.
http://mim.stupi.net/manuals/rsx/tkb.pdf, page A-25 (pg. 501).

Johnny

On Friday, April 8, 2022 at 10:32:31 PM UTC-4, gah4 wrote:
> On Thursday, April 7, 2022 at 6:51:26 AM UTC-7, gah4 wrote:
(snip)
> The assembler supplies a program for the linker to calculate
> the relocated value. And I suspect that, like the unusual cases
> for OS/360, it is not commonly used.
>
> In any case, as with any rarely used feature, it isn't easy to get
> tested well, and also not easy to find instance of its use.

ISTR the Stanford one-pass assembler FAIL (from SAIL!) generated polish.
It was blindingly fast, especially when used with LOADER.