W/o location independence and requiring executable image to be otherwise preloaded to have address constants to be modified to their executing position ... would have required every executing program image to have
unique address across the whole system
I?ve never programmed the PDP-8, but, as I understand it, its 7-bit
address field in the 12-bit instruction format effectively divides the 4096-word address space into 128-word ?pages?. An 8th bit specifies
which page the address field is interpreted relative to: either a
6502-like zero page, or the current page. So, in effect, you have two
5-bit ?base registers?: one hardwired to 00000, and the other one that?s
the high 5 bits of the program counter. (Later PDP-8s extended the
address bus to the left and needed additional registers to select which 12-bit memory space you were running in.)
I?ve never programmed the PDP-8, but, as I understand it, its 7-bit
address field in the 12-bit instruction format effectively divides the >4096-word address space into 128-word ?pages?. An 8th bit specifies
which page the address field is interpreted relative to: either a
6502-like zero page, or the current page. So, in effect, you have two
5-bit ?base registers?: one hardwired to 00000, and the other one that?s
the high 5 bits of the program counter. (Later PDP-8s extended the
address bus to the left and needed additional registers to select which >12-bit memory space you were running in.)
To reference words in other pages (again, as I understand it), you would >store their absolute 12-bit address in a word in either the zero page or
your current page, and set the indirection bit in your instructions to
use that address as a pointer. But often you would receive that pointer
at run time, for example as a return address or an argument.
It occurred to me that a subroutine or set of related subroutines that
fit into a single 128-word page could be ?position-independent? merely
by containing no absolute 12-bit addresses when loaded. ...
By comparison TSS/360 kept an external map for each virtual address
space .... where its programs were loaded. Issue was initially virtual >address space was 16 1mbyte virtual address segments. Somebody might 1st
load the fortran compiler into its segment one and somebody else might
have first loaded something else into segment one and then also wanted
to load the ("same") fortran compiler image into its virtual address
space.
The OS/360 paradigm wouldn't support it ... it needed either
1) a different copy of the fortran compiler image loaded, if it was to
run at different address or
2) had a predefined location for every application in the system (in
order to have virtual address space to have a single shared application >image). With only 16 shared segments, would only be able to have 16 >locations for predefined "shared image" application copies.
According to Lynn Wheeler <lynn@garlic.com>:
By comparison TSS/360 kept an external map for each virtual address
space .... where its programs were loaded. Issue was initially virtual
address space was 16 1mbyte virtual address segments. Somebody might 1st
load the fortran compiler into its segment one and somebody else might
have first loaded something else into segment one and then also wanted
to load the ("same") fortran compiler image into its virtual address
space.
The OS/360 paradigm wouldn't support it ... it needed either
1) a different copy of the fortran compiler image loaded, if it was to
run at different address or
2) had a predefined location for every application in the system (in
order to have virtual address space to have a single shared application
image). With only 16 shared segments, would only be able to have 16
locations for predefined "shared image" application copies.
What TSS actually did was to divide each module into position independent read-only CSECTs and relocatable read-write PSECTs, and extend the calling sequence so each routine had a pair of addresses, the code address in its CSECT and the base of its data PSECT. So all of the CSECT pages were
shared, and the PSECT pages had a separate copy in each process.
See my book for more details.
OS/360 compilers generated TXT decks that had RLD (relocation directory) unresolved addresses for other programs that were being loaded in one
large group (their "ESD" entry, the ID of program being referenced and displacement within the program). The "loader" would resolve the "fixed" desired addresses (from combination of ESD and displacement) before execution.
Lynn Wheeler <lynn@garlic.com> posted:
OS/360 compilers generated TXT decks that had RLD (relocation directory)
unresolved addresses for other programs that were being loaded in one
large group (their "ESD" entry, the ID of program being referenced and
displacement within the program). The "loader" would resolve the "fixed"
desired addresses (from combination of ESD and displacement) before execution.
It was half a century ago that I handled physical TXT card decks.
All my programs were standalone: Slap a "six-card loader" at the front of the TXT deck, and IPL.
The source code for my programs always started with
USING *,0
Did that suppress any RLDs? Don't remember. The six-card loader ignored RLDs anyway. Actually -- never one to overlook a pointless micro- optimization -- I "optimized" down to a three-card loader, good enough if
the TXT deck had no REP (hexadecimal patch) cards.
- - - - - - - - - - - -
Speaking of virtual vs physical addresses, was there any IBM operating system which could map one physical address to two different virtual addresses,
both visible from the same address space? If so, such a program MIGHT encounter an unusually weird bug on the 370/135. See
https://james.fabpedigree.com/sbe135.htm
Cheers,
James
TSS, as has been mentioned (which I don't think ran, or ever was run on
a /135).
John Levine has mentioned TSS relocation briefly. Without
analyzing it in detail I believe it was basically the same scheme as
used for Linux PIC.
According to Kragen Javier Sitaker <kragen@canonical.org>:
[...] (Later PDP-8s extended the address bus to the left and needed >>additional registers to select which 12-bit memory space you were
running in.)
Actually, the original PDP-8 had the extended addressing as an option,
adding a pair of three-bit bank registers.
It occurred to me that a subroutine or set of related subroutines that
fit into a single 128-word page could be ?position-independent? merely
by containing no absolute 12-bit addresses when loaded. ...
That's true, but I never heard of anyone doing that. PDP-8 software was pretty simple and something that swapped 128 word chunks of code could
have worked but would be way more complicated than anything I saw. TSS/8 swapped full 4K memory banks.
Actually, the original PDP-8 had the extended addressing as an option,
adding a pair of three-bit bank registers.
I appreciate the correction. So it wasn?t so much ?later PDP-8s? as it
was ?higher-end PDP-8s??
The 8086 did achieve such a sort of semi-position-independence with its >4-bit-shifted ?segment? registers, which weren?t really segments in the
usual sense, like the PDP-11 had, but it had to pay for a 16-bit wide
add on every memory access to get it. The result was that a 64-kibibyte >segment could be located anywhere in RAM, down to 16-byte granularity,
and MS-DOS took advantage of this in practice.
I suspect that a larger
shift, like 8 bits, would have been more advantageous by the mid-80s,
According to Peter Flass <Peter@Iron-Spring.com>:
TSS, as has been mentioned (which I don't think ran, or ever was run on
a /135).
Probably not, it'd be rather underpowered and I gather the only customer
for TSS/370 was Bell Labs using it as a platform for ESS development.
John Levine has mentioned TSS relocation briefly. Without
analyzing it in detail I believe it was basically the same scheme as
used for Linux PIC.
Sort of. TSS didn't have anything like the GOT which has pointers to
data in othe libraries, nor the PLT which let them keep using a single pointer to a routine.
You probably won't be surprised to hear that's in my book too.
John Levine <johnl@taugh.com> writes:
According to Kragen Javier Sitaker <kragen@canonical.org>:
[...] (Later PDP-8s extended the address bus to the left and needed
additional registers to select which 12-bit memory space you were
running in.)
Actually, the original PDP-8 had the extended addressing as an option,
adding a pair of three-bit bank registers.
I appreciate the correction. So it wasn?t so much ?later PDP-8s? as it
was ?higher-end PDP-8s??
It occurred to me that a subroutine or set of related subroutines that
fit into a single 128-word page could be ?position-independent? merely
by containing no absolute 12-bit addresses when loaded. ...
That's true, but I never heard of anyone doing that. PDP-8 software was
pretty simple and something that swapped 128 word chunks of code could
have worked but would be way more complicated than anything I saw. TSS/8
swapped full 4K memory banks.
Yes, I think it would be hard to justify such a thing when you had 4096 instructions for your whole program. I think there?s probably some
middle ground of CPU sizes, maybe something roughly Nova-sized, where
such a semi-position-independent scheme would have been a good tradeoff, where you had room for tens or hundreds of thousands of instructions
rather than single-digit thousands like the -8. That would have allowed
you to avoid *both* a slow load-time relocation pass *and* the adder necessary to offset all memory accesses by a base register, like most
PDP-11s ended up having.
And, once you have room for millions of instructions, you can probably
afford the adder.
The 8086 did achieve such a sort of semi-position-independence with its 4-bit-shifted ?segment? registers, which weren?t really segments in the
usual sense, like the PDP-11 had, but it had to pay for a 16-bit wide
add on every memory access to get it. The result was that a 64-kibibyte segment could be located anywhere in RAM, down to 16-byte granularity,
and MS-DOS took advantage of this in practice. I suspect that a larger shift, like 8 bits, would have been more advantageous by the mid-80s,
but you don?t avoid the adder unless you?re swapping full 64-kibibyte
memory banks, TSS/8-style.
808x segments were the worst of all possible worlds. I still can't
wrap my head around the fact that there were multiple ways of
encoding the same address.
John Levine <johnl@taugh.com> writes:
According to Kragen Javier Sitaker <kragen@canonical.org>:
[...] (Later PDP-8s extended the address bus to the left and needed >>>additional registers to select which 12-bit memory space you were
running in.)
Actually, the original PDP-8 had the extended addressing as an option,
adding a pair of three-bit bank registers.
I appreciate the correction. So it wasn?t so much ?later PDP-8s? as it
was ?higher-end PDP-8s??
It occurred to me that a subroutine or set of related subroutines that >>>fit into a single 128-word page could be ?position-independent? merely
by containing no absolute 12-bit addresses when loaded. ...
That's true, but I never heard of anyone doing that. PDP-8 software was
pretty simple and something that swapped 128 word chunks of code could
have worked but would be way more complicated than anything I saw. TSS/8
swapped full 4K memory banks.
Yes, I think it would be hard to justify such a thing when you had 4096 >instructions for your whole program.
It was half a century ago that I handled physical TXT card decks.
All my programs were standalone: Slap a "six-card loader" at the front of the TXT deck, and IPL.
The source code for my programs always started with
USING *,0
Did that suppress any RLDs? Don't remember. The six-card loader ignored RLDs anyway. Actually -- never one to overlook a pointless micro- optimization -- I "optimized" down to a three-card loader, good enough if
the TXT deck had no REP (hexadecimal patch) cards.
Without analyzing it in detail I believe it was basically the same
scheme as used for Linux PIC.
On Sun, 13 Sep 2026 07:45:18 -0700, Peter Flass wrote:
Without analyzing it in detail I believe it was basically the same
scheme as used for Linux PIC.
Linux distros commonly use ELF for their userland executable/linkable
format these days. That originally came from AT&T, I believe.
On Sun, 13 Sep 2026 07:45:18 -0700, Peter Flass wrote:
Without analyzing it in detail I believe it was basically the same
scheme as used for Linux PIC.
Linux distros commonly use ELF for their userland executable/linkable
format these days. That originally came from AT&T, I believe.
On 9/14/26 21:21, Lawrence D?Oliveiro wrote:
On Sun, 13 Sep 2026 07:45:18 -0700, Peter Flass wrote:
Without analyzing it in detail I believe it was basically the same
scheme as used for Linux PIC.
Linux distros commonly use ELF for their userland
executable/linkable format these days. That originally came from
AT&T, I believe.
That's only the wrapper. I was thinking about the underlying
mechanism.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 497100:49:51 |
| Calls: | 182 |
| Files: | 744 |
| D/L today: |
38 files (5,920K bytes) |
| Messages: | 73,594 |