Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Translating 64-bit addresses Message-ID: Date: 28 Feb 91 18:34:57 GMT References: <6590@hplabsz.HP.COM> <12030@pt.cs.cmu.edu> <6626@hplabsz.HP.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 59 Nntp-Posting-Host: odin In-reply-to: connors@hplabsz.HP.COM's message of 25 Feb 91 23:03:30 GMT On 25 Feb 91 23:03:30 GMT, connors@hplabsz.HP.COM (Tim Connors) said: connors> In article <6590@hplabsz.HP.COM>, connors@hplabsz.HP.COM (Tim connors> Connors) writes: connors> What about inverted page tables. Would they be any better for connors> 64 bit addresses? Does this make life tough for the MACH connors> operating system? connors> In article <12030@pt.cs.cmu.edu> af@spice.cs.cmu.edu connors> (Alessandro Forin) writes: af> May I humbly ask which original reading of our code prompts you this af> question ? Oh, I think he is referring to the fact that in the Mach kernel one of the pager modules is specifically designed to deal with inverted page tables. connors> [ ... ] HP's PA-RISC machines and the IBM RT and RS6000. My connors> understanding is that in each of these machines the inverted connors> page table scheme comes with an assumption of NO address connors> aliasing. [ ... ] As I understand MACH, address aliasing is of connors> primary importance. I can answer here for the Mach people. One of the first Mach implementations was for the RT. They did make it work on the RT, despite tha aliasing problem. The describe the solution (a variant on the obvious "remap aliased things when they are used" theme) as not pretty, but it works quite well. Actually the Mach page table code is *designed* to work also with inverted page tables, something that is not that true with other common Unix kernels (even if 4.3BSD was hacked to work on the RT too). Naturally one pays a performance penalty. The problem is historical; there is no conceptual good reason to have shared memory or copy on write, but if you want to have Unix like semantics (e.g. fork(2)), then you really want them both, because the perfomance is even worse without. Mach's success is largely because it is Unix compatible, not because it is "better" (the "better" things were in Accent, and Accent withered). It is Unix that is built around the assumption of aliasing to a large extent (shared text, SysV IPC, BSD mmap(2)) or that makes copy-on-write so desirable ("copy" semantics are prevalent because on a PDP-11 it was simpler and maybe faster to copy small things than to share them). Inasmuch Mach is Unix compatible, one needs to make the best of a mismatch, like that between inverted page tables (which are at their best supporting ORSLA/Ssystem38 type systems, that is capability based sparse address space architectures) and Unix semantics, and the Mach kernel does it with reasonable efficiency, precisely because one of the first machines it supported in large numbers was the RT. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk