Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: SunMMU history Message-ID: Date: 20 Jan 91 19:19:55 GMT References: <1991Jan19.133914.23871@bellcore.bellcore.com> Sender: cho@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 59 Nntp-Posting-Host: teacho In-reply-to: mo@messy.bellcore.com's message of 19 Jan 91 13:39:14 GMT On 19 Jan 91 13:39:14 GMT, mo@messy.bellcore.com (Michael O'Dell) said: mo> Various people have posted here recently expounding on the clear and mo> obvious (to them) botches of the original SunMMU design. One thing mo> to keep in mind is that Sun was shipping systems with virtual memory mo> LONG, LONG before the 68881 was little more than a "gee I wish I mo> had" dream. The 68451 was not that long coming, and could be used as a TLB. Yes, it was slow. As to the issue of whether it is better to add a wait state or to make the entire system thrash in the pager, it all depends on whether you sell to people that believe benchmarks run on machines with infinite central memory or on whether your customers want real system performance under load. Sun made the correct marketing move, I surmise :-(. mo> Because the mmu had to be done in random logic (asics and such mo> weren't there then), [ ... ] Yes, this is well known. There are two observations: 1) A lot of other manufacturers had the same problems. Nobody botched it quite as badly as Sun. 2) Sun persisted in the same type of design well past where it had made sense, if ever. It is like, let me repeat, the madness of System V doing expansion swaps ten years after V7 on a PDP-11. mo> THe question of when is it defensible to take the time to redo the mo> MMU (again) is another matter. Not to mention that they botched the first SPARC MMU as well. mo> All the new SPARC chipset machines have more a classic page-table in mo> memory, hardware-reloaded TLB MMU/cache controller chips. (This is mo> the "reference MMU", I haven't yet heard of a Sun product with the "reference MMU". There is malicious and obviously unfounded speculation that this is so cloners will not be able to run a binary of SunOS identical to Sun's. From the BYTE account of a couple of SPARC clones, neither used the reference MMU, to be more compatible with the SparcStation. mo> and it has a 4k pagesize, basically.) Incidentally, even a 4KB pagesize is still too large, even if it is barely tolerable. 8KB was simply crazy, for a workstation/time sharing server. Surely in due time even Sun will put out a machine with the reference MMU; as of now they'd rather sell you for a pretty steep price a patch to SunOS that corrects some of the worst software problems that accompany the design mistakes of the current SPARC MMU. -- 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