Re: ancient OS history, ARM is sort of channeling the IBM 360

John Dallman wrote:

In article <v5rcui$fqgj$1@dont-email.me>, tkoenig@netcologne.de
(Thomas Koenig) wrote:
 

Imagine a process which resides at a certain address.  It contains
code, data, and pointers to data.  Now you swap it out and want
to reload it.  You can use the same base address, then everything
is fine.  Or you can use a different one, where do the pointers
point, especially registers which contain addresses?
 
The /360 tried to solve this via base pointers, which all addresses
were supposed calculated relative to to.  Hence the RX and RS
instraction all had a base register + 12 bit offset for their
addressing modes - swapping out the base registers (if you knew
which ones they were, was this info in the executable?)  should have
worked.  But the SS instructions for decimal arithmetic did not have
base pointers, so that solution did not work in the general casse.

 
And only a 12-bit offset, to boot. I've read of systems with base and
limit registers, where all accesses were offsets from the base (or
separate base registers for code and data).

Yes, e.g. Univac 1108.

Real-mode 8086 code can
work that way, although I don't think you can limit the size of a
segment to less than 64KB. It looks as if /360 tried to construct
that kind of operation style from more general base register address
modes, but didn't do the job thoroughly.
 

Going to virtual memory from the start would have saved the
base pointer issue, and would have allowed 16-bit displacements,
also saving registers in the case where 12-bit displacements were
not enough.

 
Virtual memory was pretty new technology at the time, and required a
disk or drum. The central idea of /360 was having the same ISA across
a wide range of machines, and virtual memory wasn't affordable at the
low end at the time, AFAICS.

But IIRC even low end S/360s required a disk, at least to IPL(boot)
from.  But Virtual memory is more expensive than the hidden base
registers, as you need page tables. probably a TLB, etc.

 

So the problem wasn't with MFT memory management APIs or their
implementation, but that a /360 site had to find a set of partition
sizes that allowed for all the combinations of programs that they
needed to run simultaneously. This was inevitably wasteful of memory,
because each partition had to allow for the largest program that
could be required to run in it.
 
Is that correct?

That is correct for OS/MFT, but not for OS/MVT.



--
 - Stephen Fuld
(e-mail address disguised to prevent spam)