Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Sun, 30 Jun 2024 16:30:27 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <v5s173$jl70$1@dont-email.me>
References: <v5rcui$fqgj$1@dont-email.me> <memo.20240630131648.956b@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 30 Jun 2024 18:30:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="654a1831c01f9f66d69c6db8106c14a9";
	logging-data="644320"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19qfozDAoh+XOMsXOwVsMcR6W90Jd+yWk8="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:fdRdeXPDGjvVxlMPpBfWBQWcYFg=
Bytes: 3727

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)