eachus@mbunix.mitre.org (Robert Eachus) (06/10/89)
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
jms@tardis.Tymnet.COM (Joe Smith) (06/10/89)
In article <377@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: > ... 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). >Doug Merritt {pyramid,apple}!xdos!doug >Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary Parts of this prediction are already here. BiiN (formed by Intel + Siemens) has a system with 2**26 address spaces. Any of which can be shared or private, at the programmer's whim. A process can ask the OS to create an address space which refers one structure in an array of structures, and then pass an Access Descriptor (pointer) of this limited address space to another process. Even if the second process is buggy, and tries to write at random offsets from the pointer, the first process is protected since the hardware limits what the second process is allowed to access. Implementations along these lines have much more than just pointers to char, int, double, etc. A "pointer to file" has meaning to the hardware page table. (Functions such as lseek() become superfluous with memory mapped files.) But back to the present Amiga discussion: I grew up with an OS that has private address spaces so that process A cannot meddle with process B, maliciously or accidentally. In fact, process A cannot even see process B's address space unless they both issue calls to the OS to grant shared access. The first step that I think most of us would agree on is to make the shared libraries be read-only (and provide a mechanism to allow a library to tell the exec that is wants temporary read-write access to its private structures). This will prevent problems such as a random pointer wiping out part of the FastFileSystem (code or data) and wiping out your hard disk. -- Joe Smith (408)922-6220 | SMTP: JMS@F74.TYMNET.COM or jms@tymix.tymnet.com McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-D21 | PDP-10 support: My car's license plate is "POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (06/13/89)
jms@tardis.Tymnet.COM (Joe Smith) Writes:
:Parts of this prediction are already here. BiiN (formed by Intel + Siemens)
:has a system with 2**26 address spaces. Any of which can be shared or
:private, at the programmer's whim. A process can ask the OS to create an
:address space which refers one structure in an array of structures, and
:then pass an Access Descriptor (pointer) of this limited address space to
:another process. Even if the second process is buggy, and tries to write
:at random offsets from the pointer, the first process is protected since the
:hardware limits what the second process is allowed to access.
:
:Implementations along these lines have much more than just pointers to char,
:int, double, etc. A "pointer to file" has meaning to the hardware page table.
This sounds like Multics... nothing new at all. It turned out that
(w/ Multics) the overhead made for very slow memory access as well as a huge
overhead for inter process / shared library calls.
-Mattdoug@xdos.UUCP (Doug Merritt) (06/13/89)
In article <8906122014.AA25923@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: >jms@tardis.Tymnet.COM (Joe Smith) Writes: >:Parts of this prediction are already here. BiiN (formed by Intel + Siemens) >:has a system with 2**26 address spaces. Any of which can be shared or > > This sounds like Multics... nothing new at all. It turned out that >(w/ Multics) the overhead made for very slow memory access as well as a huge >overhead for inter process / shared library calls. Well sure, "there's nothing new under the sun". But the fact that Multics did something badly doesn't mean much...it had high overhead for many things. Unix itself was a reaction to Multics, and it implemented some inefficient Multics features in an efficient way. Consider, by analogy, garbage collection. It has been implemented inefficiently many times. Does that mean it will always be high overhead, and therefore always left out of e.g. systems programming languages? Not at all... although I'm not up on the best algorithms, a researcher at XEROX PARC told me recently that the GC algorithm they're using in their YGGDRASIL hypertext system consumed only 5% of the runtime. Or consider the Intel 432, which supports objects in a slow kind of way. Then compare that with the implementation of the Smalltalk 80 kernel. It's often true that powerful ideas languish until implementation technology progresses to the point where "very slow" becomes "acceptably fast". Sometimes this happens through hardware advances (e.g. remotely mounted file systems became widely acceptable when reasonably fast LAN technology became cheap), other times through software advances (development of more efficient algorithms). My posting that Joe responded to didn't say anything at all about "new" technologies; it was talking about those things becoming common rather than curiosities. Surely you don't think that the general kind of system architecture that is so popular today will still be widely used, say, fifty years from now??? Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
peter@sugar.hackercorp.com (Peter da Silva) (06/15/89)
In article <55595@linus.UUCP>, eachus@mbunix.mitre.org (Robert Eachus) writes: > 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. A significant exception, at least for this forum, is UNIX. > 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. (Raised eyebrow) Don't you mean harder? You can't write generally position independant code on the 68000. You can't write to a PC-relative location, so you have to burn an address register. > 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. No, the Amiga doesn't require this. When LoadSeg runs it actually patches all the code to the specific load address. This makes swapping, um, painful. -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`
mph@behemoth.phx.mcd.mot.com (Mark Huth) (06/16/89)
In article <55595@linus.UUCP> eachus@mbunix.mitre.org (Robert I. Eachus) writes: >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 > > 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. Sorry, the Amiga relocates stuff at load time - thats what the REL32 hunk types are for. The object code I've looked at on the Amiga is a curious mixture of PIC and bound code, with base register addressing thrown in for library references. The Amiga allows just about any type of code to be written and loaded, just as the 68000 support most addressing modes - and by the time you get to the '020+ you finally get full support for PIC. The 68000 PC relative addressing is limited to +/- 32k bytes. Mark Huth
daveh@cbmvax.UUCP (Dave Haynie) (06/19/89)
in article <55595@linus.UUCP>, eachus@mbunix.mitre.org (Robert Eachus) says: > Keywords: virtual memory, address space > Summary: Physical addresses will still be needed > In article <377@xdos.UUCP> doug@xdos.UUCP (Doug Merritt) writes: > 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, Well, actually, the Amiga does do relocation on absolute hunks during a code load. It's important to be able to have full 32 bit addressing -- plain 68000 relative (eg, position independent) addressing only allows a relative address space of 64K, which is fine for smaller programs, but ugly for large ones. > and on the 68000 family this type of code is generally faster. That's certainly true, and in fact, most of the Amiga compilers these days allow code and data to be relative, which as I said, makes sense for smaller programs. >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. Well, actually I map everything as 128K "pages" (except I/O devices mapped with the CARDROM file in SetCPU V1.5, which get subtables mapped on smaller (I think 8K) boundaries. For a 16 meg system you have 128 table entires, and so will occasionally have an ATC miss, though I'm not sure this could actually be noticed (The MMU will find the page entry very quickly, since except for CARDROM translations it's only a 1-level page table). I supposed I could build a smaller table, and my do just that as folks start to commonly have memory outside of the 68000's 24 bit space. The 68030 has a smaller ATC, but also have these transparent translation registers, which I may use in the future to more efficiently map things. > Robert I. Eachus -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
451061@UOTTAWA.BITNET (Valentin Pepelea) (06/20/89)
Dave Haynie <daveh@cbmvax.uucp> writes in message <7096@cbmvax.UUCP> > For a 16 meg system you have 128 table entires, and > so will occasionally have an ATC miss, though I'm not sure this could > actually be noticed (The MMU will find the page entry very quickly, since > except for CARDROM translations it's only a 1-level page table). The size of the 128 pages that you use is irrelevant, since the MMU will store in the ATC one entry for each page, where the page size is stored in the PS field of the TC register. In SetCPU 1.4 you use a rather wierd TC setup, where the pagesize is 4K. That means that there is an ATC entry for each 4K page, right? Wrong! The ATC stores page descriptors also according to function codes, wether you use them or not. In other words, you get a lot more ATC misses then you thought, eh? So if you want to improve a little your ATC hit ratio, simply rearrange your TC register to use 32K pages. Thus the hit ratio will improve by 1/exp(32/4). Pretty good tip, eh? > The 68030 has a smaller ATC, What I said holds true for the 68851. I just bought the 68030 manual, and will soon be able to tell what best goes for it. >Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" Valentin _________________________________________________________________________ "An operating system without Name: Valentin Pepelea virtual memory is an operating Phonet: (613) 231-7476 (New!) system without virtue." Bitnet: 451061@Uottawa.bitnet Usenet: Use cunyvm.cuny.edu gate - Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CA