Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: Date: 7 Mar 91 13:31:29 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 26 In article pcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) writes: > I would however still maintain that even with conventional multiple > address space architectures shared memory is not necessary, as sending > segments back and forth (remapping) gives much the same bandwidth. I don't think you can really make a good case for this. Consider the 80286, where pretty much all memory access for large programs is done by remapping segments. Loading a segment register is an expensive operation, and is to a large extent the cause of the abysmal behaviour of large programs on that architecture. For an extreme case, the sieve slows down by a factor of 11 once the array size gets over 64K. My own experience with real codes under Xenix 286 bears this out. Think of the 80286 as an extreme case of what you're proposing. I think it's clear from this experience that frequent reloading of segment registers is a bad idea. After your discussion of the inappropriate use of another technology, networks, I would have expected you'd know better. As for single address space machines, my Amiga 1000's exceptional performance... given the slow clock speed and dated CPU (7.14 MHz 68000)... tends to suggest that avoiding MMU tricks might be a good idea here as well. The Sparcstation 2 is the first UNIX workstation I've seen with as good response time to user actions. It's only a 27 MIPS machine... or approximately 40 times faster. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"