Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: Date: 9 Mar 91 19:42:11 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> <19551@cbmvax.commodore.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 139 Nntp-Posting-Host: aberdb In-reply-to: jesup@cbmvax.commodore.com's message of 6 Mar 91 04:41:41 GMT On 6 Mar 91 04:41:41 GMT, jesup@cbmvax.commodore.com (Randell Jesup) said: jesup> In article jesup> pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: pcg> there is no conceptual good reason to have shared memory... And practical as well, let me add, except for historical re peter> Shared libraries? pcg> [ ... yes, but only if you have multiple address spaces, and only pcg> as irrevocably read only data. With 64 bit addresses one had better pcg> have single address space systems ... ] jesup> Shared libraries are very useful on systems with single address ^^^^^^ Probably you mean multiple here; in single address space systems all libraries are "shared". jesup> spaces. [ ... ] Ah yes, of course. One of the tragic legacies of the PDP-11 origin of Unix is that shared libraries have been so slow in appearing. Not all is a win for shared libraries (one has to be careful about clustering of functions in shared library), but I agree. pcg> Naturally, except on the AS/400, single address space machines are pcg> pie-in-sky technology (even if more or less research systems abound). jesup> I wouldn't quite say that. The Amiga (for example) uses a jesup> single- address-space software architecture on 680x0 CPUs. It jesup> currently doesn't support inter-process protection (partially jesup> since 80% of amigas don't have an MMU), This is quite an empty claim. Naturally all machines without an MMU have a single (real) address space, from the IBM s/360 to the Apple II to the PC/XT. The point lies precisely in having inter process protection... jesup> but if it were implemented (it might be eventually), it would jesup> almost certainly continue to use a single address space. It will be interesting to see how you do it on a machine with just 32 bits of addressing. You cannot do much better than having 256 regions of 16MB each, which in today's terms seems a bit constricting. Not for an Amiga probably, admittedly. Amiga users are happy with 68000 addressing, because its sw is not as bloated as others. There are other problems. Psyche from Rochester does something like that, when protection is not deemed terribly important; it maps multiple "processes" in the same address space, so that they can enjoy very fast communications. pcg> I would however still maintain that even with conventional multiple pcg> address space architectures shared memory is not necessary, as pcg> sending segments back and forth (remapping) gives much the same pcg> bandwidth. jesup> It requires far more OS overhead to change the MMU tables, The Mach people have been able to live with it on the ROMP; not terribly happy, but the price is not that big; "far more" is a bit excessive. Point partially acknowledged, though; I had written: pcg> Naturally one pays a performance penalty. The problem is pcg> historical; jesup> and requires both large-grained sharing and program knowlege of jesup> the MMU boundaries. But this is really always true; normally you cannot share 13 bytes (in multiple address space systems). As a rule one can share *segments*. Some systems allow you to share single *pages*, but I do not like that (too much overhead, little point in doing so, most MMUs support much more easily shared segments than pages; even the VAX has a 2 level MMU with 64KB shared segments, contrarily to common misconceptions). Here I feel compelled to restate the old argument: if shared memory is read-only, it can well be *irrevocably* read-only and require no actual remapping, so no problems. If it is read-write some sort of synchronization must be provided. In most cases synchronization must instead be provided via kernel services, and in that case it is equivalent to remapping, so simultaneous shared memory is not needed. Taking turns via semaphores to access a segment that is always mapped at the same time in multiple address spaces is not any faster than remapping, even explicitly, the segment in one process at a time. I know that on machines with suitable hardware instructions and when spin locks are acceptable one wins with simultaneous shared memory, but this I bet is not that common for inter address space communication, and there are better alternatives (multiple threads in the same address space). Explicit remaps involve a small change in programming paradigm, in that it is neither simultaneous shared memory, nor message passing (which implies copying, at least virtually). Its one major implementation, as far as I know, is in MUSS. IMNHO it can be easily demonstrated that remapped memory is superior both to simultaneous shared memory (automatic synchronization, no problems with reverse MMUs, the distributed case is simple, no address aliasing hazards) and to message passing (no copying or copying-on-write, no data aliasing, much simpler to implement). The only loss I can conceive of is when there are mostly readers and occasional writers, but this can be handled IMNHO more cleanly with versioning on irrevocably read only segments. Consider the two process case; in the left column we have traditional shared memory, in the right column we have nonshared memory: p1: create seg0 p1: create seg0 p1: create sem0 p1: map seg0 p1: down sem0 ... p2: map seg0 p2: map seg0 (wait) p2: down sem0 (wait) ... ... ... p1: up sem0 p1: unmap seg0 ... ... p2: (continue) p2: (continue) ... ... p1: down sem0 (wait) p1: map seg0 (wait) ... ... p2: up sem0 p2: unmap seg0 ... ... p1: (continue) p1: (continue) ... ... The contents of the message passing column is left to the reader. Final note: I am amazed that a simple and efficient idea like remapped read-write memory and shared irrevocably read only segments is not mainstream, and much more complicated or inefficient mechanisms liek shared memory and message passing are. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk