Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!elroy!ucla-cs!uci-ics!zardoz!tgate!irsx01!ka3ovk!drilex!axiom!linus!mbunix!eachus
From: eachus@mbunix.mitre.org (Robert Eachus)
Newsgroups: comp.sys.amiga.tech
Subject: Address Spaces (was Re: (Fairly) Complete Amiga VM design)
Summary: Physical addresses will still be needed
Keywords: virtual memory, address space
Message-ID: <55595@linus.UUCP>
Date: 9 Jun 89 17:08:59 GMT
References: <8906010252.AA11810@jade.berkeley.edu> <367@xdos.UUCP> <54912@linus.UUCP> <377@xdos.UUCP>
Sender: news@linus.UUCP
Reply-To: eachus@mbunix.mitre.org (Robert I. Eachus)
Organization: The MITRE Corporation, Bedford, Mass.
Lines: 119

In article <377@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes:

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

     On almost all "separate address space" time-sharing systems, part
of the address space (managed by the OS) is mapped into all user
adress spaces.  VM for IBM mainframes is probably the only major
exception.

>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 Unix and VMS for the VAX were decended from OS's which
required multiple memory images, since code was bound to run at
specific locations in memory.  However, beginning with the PDP-11, a
technique called position independant code was available which
permitted code to be loaded without relocation.  The VAX and 68000
were both desinged to support this since it made linking and loading
much easier.

     The Amiga from day one has required that code be written this
way, and on the 68000 family this type of code is generally faster.
Why go back?  If you have PIN code and a "flat" address space
performance will be much better than memory mapping and VM.  The
easiest way to explain the difference is to compare an Amiga 2500 to a
Sun 3/60.  The Amiga is so much faster in part because you have
two or more fewer clock cycles for EVERY off-chip memory reference,
data or instruction.

     This interaction is sometimes hard to explain without saying read
the MC68030 instruction timings.  Note that the OS services will need
to use MOVES to go from one address space to another, and that in a
flat address space that even if memory mapping is turned on, the on
on-chip translation cache will always contain the necessary page entry
since there are so few of them.  You would have to ask Dave Haynie,
but I assume that if ROM is remapped he sets up four or five table
entries to cover all of memory.

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

> Doug replied...
>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").

     Upward compatibility was required both by marketing and the fact
that an existing operating system was revamped, instead of starting
with a fresh sheet of paper.  In the early years most VAX compilers
were actually PDP-11 compilers which generated compatibility mode
code, so you had to use that "feature".

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

     If you don't believe Gordon Bell, I could show you a chart which
plots processor family member introductions (with address sizes)
versus time in five groups (supercomputer, mainframe, small business
system, minicomputer, and micro).  Families die when they hit the hard
limit for their class, and no new models are introduced.  If you look
at the pounding that IBM took in converting their mainframes from 24
to 31 bit addressing, and is going through now breaking the 31-bit
physical barrier, you wouldn't be so complacent about 30 bits being
sufficient to allow flat addressing on VAXes today.  

     The Amiga is in the micro class, so 32-bits flat should last us
for a while, but note that the 24-bit physical limit on the low end
Amigas is starting to pinch.  I have currently have 5 Meg in my 2000
at work. I will probably upgrade to a 68020 or 68030 processor within
a year, but that decision will almost certainly be driven by a need
for more memory.  Most Suns around here used for similar work have 16
Meg of RAM.

Doug again...
>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).

     Non-von and OO architectures are interesting, and non-flat memory
spaces have been around for about 15 years, but they all still contain
memory addresses.  Multics, where in theory there was no distinction
between disk and main memory, and pointers are huge, is being killed
off.  At least part of the reason is hitting the addressing limit.
Segments are 256K of 36-bit words max, and it is possible to create
Multi-segment objects (or files), but the normal indexing limit is one
segment, and a process can only address 4096 segments.  That may sound
like four gigabytes, but most segments are small so it really works
out to about 20 or thirty megabytes, and remember that includes files
(but not databases).

					Robert I. Eachus