murphy@hao.UUCP (04/30/87)
Having recently spent a weekend getting undump to work on an
Integrated Solutions 68020 machine, I would agree that binary
compatibility is not yet a viable possibility for the high-performance
unix machines around. The reason being IS decided to change the format of their
executable files from the Berkeley Vax format. Not unreasonable,
but annoying.
I have two questions regarding MMU's :
1) Why have so many 68020 OEM's gone to their own MMU's instead of using
the Motorola unit, and is it possible that the 68030 might end-up
being ignored for the same reasons (though the applications
are likely to be different) ?
2) Regarding binary compatibility, how does an MMU effect things at all ?
On cpu's with linear addressing, such as the 68020, compilers can, and
do, designate specifc areas for various purposes, (i.e. executable,
data sections etc.) without any regard to real physical memory capability.
It is surely up to the LOADER to take the binary and put it where the
MMU can find it when needed. So long as the executable file has the same format,
only the loader need be MMU, and therefore, device dependent which would hardly
come as a surprise. What part am I missing ?
Graham Murphy
High Altitude Observatory
National Center for Atmospheric Research
UUCP: {hplabs, seismo, nbires, noao}!hao!murphy
CSNET: murphy@ncar.csnet ARPA: murphy%ncar@CSNET-RELAY.ARPA
INTERNET: murphy@hao.ucar.edu
NOT-NET: P.O. Box 3000, Boulder, CO 80307-3000. (303) 497-1514.
--
(And occasionally: murphy_g@summer.su.oz)mash@mips.UUCP (04/30/87)
In article <611@hao.UCAR.EDU> murphy@hao.UUCP (Graham Murphy) writes: >..., I would agree that binary >compatibility is not yet a viable possibility for the high-performance >unix machines around.... >I have two questions regarding MMU's : >1) Why have so many 68020 OEM's gone to their own MMU's instead of using >the Motorola unit, and is it possible that the 68030 might end-up >being ignored for the same reasons (though the applications >are likely to be different) ? Why: 1) When people started (with 68000/68010), there weren't Moto MMUs available in a timely fashion. 2) Even when there were, they've often been slower than the designs people could make with fast SRAM-based designs. People doing small VME boards often included the MMUs, for space reasons. Most workstation vendors [who generally use large boards] and people making larger supermicro multi-user systems [who also tend to use large boards] have used SRAM-based designs. Will people ignore the 68030? Probably not. On a cursory examination, the MMU in it looks flexible enough to accomadate different environments, although with just 22 entries in the on-chip TLB, system designers should be careful with choice of page size and how they use it, lest they get low hit rates in some environments. OK combinations would appear to exist. People who used SRAMs and page tables that looked a lot different will have to redo that work, and this will eitehr be a lot of work, or no big deal. At the "low" end, people should have a fairly strong motivation to switch to the 68030, simply because it finally has an MMU that doesn't cost you wait states, and because it lets you build a faster "cheap" system. This probably won't be true at the higher end, at least in some designs, until the clock rate gets above 20MHz. More specifically, on cursory examination: a) The faster non-cached implementations of 68020s tend to use SRAM-based MMUs, with good memory systems, running at 16.7MHz, to yield about 2Mips [integer performance], [where VAX/11780 4.3BSD = 1]. Example: Sun3/160. b) For easiest comparison, the Sun3/260 is usually rated at 4 Mips [accurately, I believe], running at 25MHz, using SRAM-based MMUs, 64K write-back virtual cache [so the translations can be done in parallel], and typically good Sun memory systems. [Some other vendors use different designs, with big physical caches, Moto MMUs, etc; I don't have enough data to really know how fast these are; maybe someone else can post.] THere's a good paper coming up in the June USENIX by the Sun folks on the issues of putting UNIX on virtual-cached systems. c) It would appear that the fastest "natural" non-cached 68030 design would yield up to 3 Mips [this is a gross guess, not something I've got simulatiosn for], with most of the improvement coming from the reduced bus-cycles. It is not yet to be clear if or the on-chip D-cache actually gains performance or loses it. [Small D-caches often have low hit-rates. If they're too low, you can actually lose performance. Small I-caches do work OK.] d) At the high end, with heavily-cached systems, it would appear that a 20MHz 68030 wouldn't be significantly faster than a 25MHz 68020 [in the Sun-style design, anyway]. Presumably, it will help people using physical caches, by avoiding wait states. This says that you'd expect: 20MHz: still about 4 Mips. 25MHz: about 5 Mips [this speed is not announced, but one can guess...] If I had to predict, I'd guess that a lot of vendors will be pushing very hard on the non-cached designs to get faster "cheap" systems, while playing wait-and-see at the higher end, particularly if they've invested a lot of effort in all-out 68020 designs. >2) Regarding binary compatibility, how does an MMU effect things at all ? >On cpu's with linear addressing, such as the 68020, compilers can, and >do, designate specifc areas for various purposes, (i.e. executable, >data sections etc.) without any regard to real physical memory capability. >It is surely up to the LOADER to take the binary and put it where the >MMU can find it when needed. So long as the executable file has the same format, >only the loader need be MMU, and therefore, device dependent which would hardly >come as a surprise. What part am I missing ? There are the following MMU-related variables: a) Page size [I've seen at least 1K, 4K, 8K, and I assume there must be somebody who did 2K]. b) Where is the origin of the user program? - 0 is possible - (pagesize) or higher is possible, for those who didn't want 0 in the address space [to catch null derefs] - SIZE is possible, where SIZE is >= the size of the maximum kernel, if the the kernel is part of the address space seen by the user, and if the kernel was put at the bottom. A good analysis of the issues may be found in "Memory Management Units and the UNIX Kernel", Clara S. Lai, Chris Peer Johnson, Proc. 1985 USENIX Summer Conf, June 11-14, 1985, pp. 361-370. [UNISOFT folks: a lot of experience porting to different MMU designs]. Thus, even porting the same UNIX variant to different machines yields different executables, mainly for MMU differences. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086