Path: utzoo!news-server.csri.toronto.edu!rutgers!sun-barr!lll-winken!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: Date: 15 Mar 91 18:45:58 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> <19551@cbmvax.commodore.com> <19840@cb Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 78 Nntp-Posting-Host: aberdb In-reply-to: jesup@cbmvax.commodore.com's message of 14 Mar 91 00:53:02 GMT In article pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: pcg> It will be interesting to see how you do it on a machine with just pcg> 32 bits of addressing. You cannot do much better than having 256 pcg> regions of 16MB each, which in today's terms seems a bit pcg> constricting. Not for an Amiga probably, admittedly. Amiga users pcg> are happy with 68000 addressing, because its sw is not as bloated pcg> as others. There are other problems. To this you comment repeating exactly what I say here, that is 32 bit addressability is not constricting for an Amiga because its typical applications are small and do not rely on a large sparse address space. This is unfair! You cannot object to what I say by repeating it! I could fall into the trap, not realize that your reply is just a rewording of what I have written myself, and try to show that it is wrong, and then look even more of a fool, especially if I succeed! :-). pcg> Here I feel compelled to restate the old argument: if shared memory is pcg> read-only, it can well be *irrevocably* read-only and require no actual pcg> remapping, so no problems. pcg> If it is read-write some sort of synchronization must be provided. pcg> In most cases synchronization must instead be provided via kernel pcg> services, and in that case it is equivalent to remapping, so pcg> simultaneous shared memory is not needed. jesup> But such services can be many orders of magnitude faster than jesup> remapping. jesup> An example is a program I wrote and posted to comp.os.research, jesup> concerning pipe speed versus shared memory speed to transfer jesup> data. I merely sent a shared-memory message from one process to jesup> the other saying the data was in the shared buffer. You only win if you can make assumptions about the hw environment, and not use OS sempahores, but use hw locks. Again, it would be better anyhow to have tightly communicating processes in the same address space than using shared memory. jesup> Rebuilding process page tables on each pass would have swamped jesup> the actual transfer time. Hardly, I think, given a suitable buffer size and a quick way of modifying two page table entries. I cannot imagine an implementation of remapping which is significantly more expensive than an implementation of semaphores. Again, hw locks are faster than sw remapping or sw semaphores, but of more limited applicability. And remapping after all is just something you do if you have to run applications designed for multiple address spaces on a single address space architecture. What I say is not that it's optimal, but that it is tolerable. jesup> Messages can be shared also (greatly increases message passing jesup> speed). No, the speed does not increase a lot. Unless the synchronization is done using hardware primitives, which is nonportable, or at least not always applicable. Also, my position is that messages are not as good as simply sharing in a single address space. Yet, if one does messaging for one reason or another, doing it by remapping is much better than the alternatives, and is not that much worse than shared memory. jesup> I don't think we disagree that much (partially on terminology). No, we actually don't disagree a lot, except for the part where I draw the attention to the fact that shared memory of any flavour implies some sort of synchronization, and this can only be cheaply provided under fairly limiting assumptions (but valid on an Amiga for example). -- 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