Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!hp-ses!hpcuhb!hpda!motcsd!xdos!doug
From: doug@xdos.UUCP (Doug Merritt)
Newsgroups: comp.sys.amiga.tech
Subject: Re: (Fairly) Complete Amiga VM design (was Re: MEMF_PHYSICAL?)
Keywords: virtual memory, address space
Message-ID: <377@xdos.UUCP>
Date: 7 Jun 89 01:17:06 GMT
References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP> <54912@linus.UUCP>
Reply-To: doug@xdos.UUCP (Doug Merritt)
Organization: Hunter Systems, Mountain View CA (Silicon Valley)
Lines: 110

Well, I haven't seen any responses to my Amiga virtual memory support
proposal, so I may as well respond to:

In article <54912@linus.UUCP> eachus@mbunix.mitre.org (Robert I. Eachus) writes:
>     I was there Charlie! And the reason most 70's computers gave each
>user his own address space was that they had run out of address bits,
>and putting each user in his own box, postponed the architectural doom
>date for a few more years.

I fail to see the attraction in denying that there are any reasons
besides addressing limitations for separate address spaces. On the
Amiga, as Valentin and others point out, we want (at least some) shared
address space. On multiuser timesharing systems it is often considered
desirable to have separate address spaces.

And yes, it certainly was *also* an advantage that this stretched
addressing limitations. If you consider the 1978 introduction of
the VAX 11/780 with relatively large address space, by your argument
there was no need for separate address spaces. Yet both VMS and UNIX
on the VAX supported them. Why? Because they were desired both by
the OS implementors and their users/customers. If the people who design
a machine, sell a machine, program a machine, and use a machine all
say something is useful, then there's little point in saying it isn't
useful after all...it is to *them* whether *you* need it or not.

>
>     The clearest example is the PDP-11 which started life with 16-bit
>hardware and instruction-set adresses. As this limit became more and
>more intolerable, the hardware addresses were upped (to a final figure
>I think of 22-bits), but addresses in programs were still required to
>be 16-bits max.

Nice classic example. Note that compatibility & marketing reasons are
the source of the "16 bit max" requirement, while the extra high bits
of physical address allowed for more effective timesharing (small individual
processes, but many concurrently residing in physical ram/core). In
this example, separate address spaces are *mandated* by a simple lack
of enough address bits to address all the other processes. In the VAX
separate address spaces were not necessary; it took extra hardware to
implement this feature. Yet it is a direct outgrowth of the PDP 11
architecture, with the requirement for strict binary compatibility
dropped (aside from "compatibility mode").

>Having separate data and instruction address spaces
>was added to give programmers one more effective address bit, but boy
>did it make things messy.

Depends on how you look at it. It had the secondary advantages that
you couldn't accidentally overwrite instructions, so that many people
claimed it was actually a cleaner model than the combined I&D. True,
you now have 2 address spaces, but why is that really messy? The kernel
has a separate address space than user processes, but if anything it
makes things cleaner to work with. The *really* big problem with
separate I&D is that it broke nargs(), which was the only mildly advanced
feature the C language ever had. List processing is permanently brain
damaged in C without it. (Of course, the *implementation* of nargs()
was *really* messy, but that's another story.)

>     Writing programs which do page table swapping is even messier,

Yes, but even that comparison is unfair to PDP 11 separate I&D, because
the *user* programs didn't have to manage the two address spaces, unlike
your examples like the PDP-8 and today's brain-dead favorite, the 8086.

>advantage.  But I would never, even with a gun to my head, buy a
>machine which supported more physical memory than was directly
>addressable in normal address modes.

Definitely; once you've got 32 bits of address space, you're good
for another decade. :-)

>     Gordon Bell said it all: (this may not be exact) "No computer
>architecture has ever become obsolete for any reason other than a lack
>of address bits."  He should know, he designed the PDP-15 nee PDP-1

Bell has said a lot of nifty quotable things, and I respect him. But
if he said that, he was exaggerating to make a point. All these machines
he designed were mini's, after all; that might bias his point of view.
Traditionally mini's had fewer address bits than mainframes and supers, and it
certainly did tend to cause problems down the road.

>the limit that will change.)  Recently the need for address bits has
>been increasing at a rate of almost one a year.  If we say that with 1.3
>Amigas require 1-Meg, then most of the current Amigas will run out of
>physical address space in about 3 or 4 years, but it will take another
>10 years to hit the architectural limit of the 680x0 family.  Note
>that reserving 4 Meg of address space for CHIP RAM was a foresighted
>decision.  But a new address map will be needed in say 1992, but that
>one would be needed to support more than 16 Meg on the FAST bus anyway.

Very interesting comments, thanks for the insights.
	Doug

P.S. The whole industry is fascinated with quantitative curves of
progress. Mark my words, within the next decade there will be a shift
of importance to major qualitative architectural change. Quaint notions
of fixed numbers of address bits, small fixed numbers of address spaces,
small fixed numbers of addressing capabilities/protections, etc, will
all eventually disappear, not long after non-von-neumann architectures,
object oriented architectures, hardware garbage collection, and architectural
support for dynamic data structure shaping are taken for granted rather than
being novelties. I figure on seeing this around the time that optical logic
starts replacing GaAs (unless nanocpu's get there first).

Of course, right now nobody'll care I think this, and by the time it
happens nobody'll remember I said so. Wish I could figure out something
practical to *do* with these predictions...
-- 
Doug Merritt		{pyramid,apple}!xdos!doug
Member, Crusaders for a Better Tomorrow		Professional Wildeyed Visionary