Path: utzoo!news-server.csri.toronto.edu!rutgers!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: <19840@cbmvax.commodore.com> Date: 14 Mar 91 00:53:02 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> <19551@cbmvax.commodore.com> Reply-To: jesup@cbmvax.commodore.com (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 124 In article pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: >On 6 Mar 91 04:41:41 GMT, jesup@cbmvax.commodore.com (Randell Jesup) said: >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". No, I meant "single". Single address space doesn't mean a single shared r/w address space, and it doesn't mean that all libraries are public (as opposed to private). Libraries can/are used for dynamic run-time binding as well as for code-sharing. "Single address space" means to me that there are no duplicated virtual addresses between different processes (which of course makes sharing memory/code far easier, since a pointer is valid to all processes, and libraries do not have to be position-independant). >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. Absolutely agreed. Witness the apocryphal 1Meg XClock. >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. 256 times 16Mb???!!!! Constricting?? First, why would we partition on 16Mb boundaries, when the average application uses 50-500K? Also, I can't see it being constricting until memory + swapspace is greater than 2 or 4 gigs. Constricting for a 100 user shared system, for a mini-super- computer, but not for a single-user oriented machine. 68000 addressing is restricting (24 bits), but all mmu-capable Amigas are 32-bit machines. (BTW, due to shared libs, easy interprocess communication, whatever, Amiga applications are usually far smaller than, say, the X/Unix versions of the same thing.) >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. Sounds very much like threads to me. But the protection and single address space issues are separate, IMHO. >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: This depends highly on how frequent you think passing segments is going to be. On a highly shared-message-based system like the amiga, the numbers of messages passed per second can be very high (many thousands). >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). In any protected amiga, sharing would almost certainly be on the page level. Anything else is far too inefficient in memory usage. Also, more than one object would reside in the shared memory space (i.e. AllocMem(size,MEMF_SHARED,...) or some such). This greatly cuts down on the amount of shared memory required, and the amount of real memory to hold shared pages (since the % utilization of the pages is higher). >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. But such services can be many orders of magnitude faster than remapping. An example is a program I wrote and posted to comp.os.research, concerning pipe speed versus shared memory speed to transfer data. I merely sent a shared-memory message from one process to the other saying the data was in the shared buffer. Rebuilding process page tables on each pass would have swamped the actual transfer time. >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. Messages can be shared also (greatly increases message passing speed). I don't think we disagree that much (partially on terminology). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)