Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360
Date: Sun, 30 Jun 2024 13:49:04 +0300
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <20240630134904.0000797b@yahoo.com>
References: <87ed8e7os5.fsf@localhost>
	<memo.20240630105046.956Z@jgd.cix.co.uk>
	<v5rcui$fqgj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 30 Jun 2024 12:48:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="878897f5e23d7e00958d040114fc15f1";
	logging-data="456208"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18S/9j0WsThfLYcLSGM+6NENA9e5AaEt38="
Cancel-Lock: sha1:KsAZIQi2Blqkm0lEmXFz12z3bIo=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2753

On Sun, 30 Jun 2024 10:44:34 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> John Dallman <jgd@cix.co.uk> schrieb:
> > In article <87ed8e7os5.fsf@localhost>, lynn@garlic.com (Lynn
> > Wheeler) wrote:
> >  
> >> back to IBM decision to add virtual memory to every 370 ... aka MVT
> >> storage management was so bad that regions had to be specified four
> >> times larger than used   
> >
> > What was the problem with the memory management? My experience of
> > systems without virtual memory doesn't include any that shared the
> > machine among several applications, so I have trouble guessing.    
> 
> 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?
>

Why would I want to use different address?

> 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.
> 
> 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.