Path: ...!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: interative use, The Design of Design
Date: Thu, 9 May 2024 05:08:44 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <v1hlor$fkqo$1@dont-email.me>
References: <v03uh5$gbd5$1@dont-email.me> <v1dud5$3e2c6$1@dont-email.me> <v1e0h2$15vm$1@gal.iecc.com> <v1f7as$3d5bq$1@dont-email.me> <v1gp9h$2gnu$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 09 May 2024 07:08:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8e805b391587dfc38a6b74b1cfc52567";
	logging-data="512856"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19H1UzlKRrwkFiprImNGySIjP2QhudZDRY="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:ZybT0ZT2yLPcvH3umlc1nUIQg0s=
Bytes: 2890

John Levine wrote:

> According to Stephen Fuld  <sfuld@alumni.cmu.edu.invalid>:
> >> With sufficiently disciplined programming, you could swap and move
> data >> by updating the base registers.  APL\360 did this quite
> successfully >> and handled a lot of interactive users on a 360/50.
> > 
> > Wasn't APL\360 an interpreter?  If so, then moving instructions and
> > data around was considerably simpler.
> 
> That's right.  It could switch between users at well defined points
> that made it practical to update the base registers pointing to the
> user's workspace.
> 
> >> Reading between the lines in the IBMSJ architecture paper, I get
> the >> impression they believed that moving code and data with base
> registers >> would be a lot easier than it was, and missed the facts
> that a lot of >> pointers are stored in memory, and it is hard to
> know what registers >> are being used as base registers when.
> > 
> > Interesting.  That would seem to imply that it wasn't that they
> > didn't think about the problems that base addressing would cause,
> > they just (vastly) underestimated the cost of fixing it.  A
> > different "design" problem indeed.
> 
> In Design of Design, Brooks said they knew about virtual memory but
> thought it was too expensive, which he also says was a mistake, soon
> fixed in S/370.


While I agree that virtual memory was probably too expensive in the mid
1960s, I disagree that it was required, or even the optimal solution
back then.  A better solution would have been to have a small number of
"base registers" that were not part of the user set, but could be
reloaded by the OS whenever a program needed to be swapped in to a
different address than it was swapped out to.




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