According to Stephen Fuld <[email protected]d>:

On 6/12/2025 8:00 AM, quadibloc wrote:

The IBM System/360 had a base and index register and a 12-bit
displacement.

Yes, but as I have argued before, this was a mistake, and in any event
base registers became obsolete when virtual memory became available
(though, of course, IBM kept it for backwards compatibility).

S/360's addressing was a sensible design for the time. While the address space was 24 bits, none of the early models had anywhere near that much memory. A 360/30 could have as little as 8K and a maximum of 64K. In the original 1964 system summary, the largest model was the /70 with 512K of core.

Their problem was making the instruction encoding reasonably compact for the small models, while providing flat addressing for the big models. Their design gave them that, with 16 bit address fields in the instructions, and 24 bit addressing via base registers. You might have to use several instructions when a
data structure exceeded 4K, but you didn't have to screw around trying to fit data into fixed size segments.

They were aware of dynamic address translation, and added it to the 360/67 so they could bid for the Multics project, but they believed, probably correctly, that it was too expensive to make a a standard feature. They reconsidered that pretty quickly and by 1973 even the low end 370/115 had standard virtual memory.

Later on they added PC-relative branch addressing (something I think they should
have had originally, since it is not expensive and gives you back a register) and larger displacements in new versions of many instructions. They made a mistake not reserving the high byte of address words, which was often used to store other info, so they had to come up with a 31 bit address mode kludge where
the high bit of the high byte said whether it was a 31 bit address or a 24 bit address and ignore the rest of the byte. When that filled up they invented a variety of ways to have multiple 31 bit address spaces and finally zSeries added
a flat 64 bit address mode.

The 1964 IBMSJ article on the 360 describes the design and sort of says that you
can use base registers to do relocation but I doubt they really believed it, since it doesn't work for all the reasons people have described.

TSS/360, which ran on the /67, divided each module into CSECTs which were read-only and position independent and shared among processes, and PSECTs which were writable and had a copy per process. The calling sequence put the called routine's PSECT address into a fixed place in the save area so the routine could
find its data. It was not hard to write position-independent code and this let them share CSECTs and put them at different places in different processes.
--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 14 Jun 2025 22:02:15 +0000, John Levine wrote:

According to Stephen Fuld <[email protected]d>:

On 6/12/2025 8:00 AM, quadibloc wrote:

The IBM System/360 had a base and index register and a 12-bit
displacement.

Yes, but as I have argued before, this was a mistake, and in any event
base registers became obsolete when virtual memory became available >>(though, of course, IBM kept it for backwards compatibility).

S/360's addressing was a sensible design for the time. While the address space
was 24 bits, none of the early models had anywhere near that much
memory. A
360/30 could have as little as 8K and a maximum of 64K. In the original
1964
system summary, the largest model was the /70 with 512K of core.

Their problem was making the instruction encoding reasonably compact for
the
small models, while providing flat addressing for the big models. Their design
gave them that, with 16 bit address fields in the instructions, and 24
bit
addressing via base registers. You might have to use several
instructions when a
data structure exceeded 4K, but you didn't have to screw around trying
to fit
data into fixed size segments.

They were aware of dynamic address translation, and added it to the
360/67 so
they could bid for the Multics project, but they believed, probably correctly,
that it was too expensive to make a a standard feature. They
reconsidered that
pretty quickly and by 1973 even the low end 370/115 had standard virtual memory.

Later on they added PC-relative branch addressing (something I think
they should
have had originally, since it is not expensive and gives you back a
register)

It gives you back 1 register for every floor(size)/4096 bytes that
that subroutine contained as instructions. 4KB gives back 1 register,
16KB gives back 4 registers,...

and larger displacements in new versions of many instructions. They made
a
mistake not reserving the high byte of address words, which was often
used to
store other info, so they had to come up with a 31 bit address mode
kludge where
the high bit of the high byte said whether it was a 31 bit address or a
24 bit
address and ignore the rest of the byte. When that filled up they
invented a
variety of ways to have multiple 31 bit address spaces and finally
zSeries added
a flat 64 bit address mode.

Possibly their worst mistake--compounded by having the assembler support
a high bite in a pointer.

The 1964 IBMSJ article on the 360 describes the design and sort of says
that you
can use base registers to do relocation but I doubt they really believed
it,
since it doesn't work for all the reasons people have described.

Once an application program can perform arithmetic on a base register relocation via base registers goes out the door.

TSS/360, which ran on the /67, divided each module into CSECTs which
were
read-only and position independent and shared among processes, and
PSECTs which
were writable and had a copy per process.

My memory says that PSECTs were prototype (i.e., struct definitions)
while DSECTS were data sections.

The calling sequence put the
called
routine's PSECT address into a fixed place in the save area so the
routine could
find its data. It was not hard to write position-independent code and
this let
them share CSECTs and put them at different places in different
processes.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

According to MitchAlsup1 <[email protected]>:

TSS/360, which ran on the /67, divided each module into CSECTs which
were
read-only and position independent and shared among processes, and
PSECTs which
were writable and had a copy per process.

My memory says that PSECTs were prototype (i.e., struct definitions)
while DSECTS were data sections.

PSECT was indeed prototype, i.e., use this to initialize writable storage. DSECT
was dummy section, describe the layout but don't allocate any storage. It was a way to lay out a structure, put the fields in a DSECT, put a pointer to the structure
in a register, and say USING Rn,dsectname to make it addressable. OS and other systems
used DSECTs too.

--
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)