Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.atari.st Subject: Re: "DOS machines" (Was: TT (Who has one?)) Keywords: long Message-ID: <13687@cbmvax.commodore.com> Date: 7 Aug 90 22:20:53 GMT References: <1990Jul19.135115.2032@cunixf.cc.columbia.edu> <1990Jul19.160526.2215@arcsun.arc.ab.ca> <6764@vax1.acs.udel.EDU> <692@cvbnetPrime.COM> <3160@rwthinf.UUCP> <701@cvbnetPrime.COM> <713@cvbnetPrime.COM> Reply-To: daveh@cbmvax (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 91 In article <713@cvbnetPrime.COM> jshekhel@feds19.UUCP (Jerry Shekhel ) writes: >Excuse me, but even the 68020 does not have full VM support. That's why >it requires a 68551 MMU to run UNIX. A Microprocessor's VM support has nothing to do with whether or not it's MMU is internal or external. A Microprocessor supports VM simply if it can fully recover from a page fault during an instruction. Some micros, such as the 68010-30, handle this by taking an exception when a page fault is detected, with the internal state of the CPU stored. The page is brought into memory, and the instruction continued right where it left off. Others, such as the 68040, take an exception with less context information available and actually restart the complete instruction after the page is brought into memory. An internal MMU does three things for you: 1) Usually improves translation times, since on-chip delays are always considerably less than delays between chips. 2) Simplifies system design. 3) Standardizes the MMU along with the CPU. Point #2 is perhaps the most important for Personal Computers in general, and point #3 is important if you're trying to be a clone of something, such as "IBM Compatible", but it makes little difference to Sun, Commodore, or anyone else making their own OS releases. Point #1 can be minimized in other ways, such as by employing external logical cache. Note that both 68020-based Sun 3's and SPARC based Sun 4s (eg, SparcStations) use external MMUs. Motorola 88100s and some other RISC chips also use external MMUs. They are not a big deal, and certainly have nothing to do with the ability to run UNIX. In fact the first Apollos, which did support virtual memory, used a second 68000 as an exception processor to handle the problem of no virtual exception context inherent in the 68000. >Programmers don't have to worry about these things even at the machine >language level! Unless you're writing the OS, you as programmer don't worry about how the MMU is implemented, either. >I wasn't talking about supervisor mode. I was talking about hardware >support for multitasking with an isolated memory space for each process. Multitasking, separate process spaces, and virtual memory are all separate issues. UNIX-like things such as OS/9 have been used for years without translating MMUs. And a very simple MMU hooked up to a 68000 could run a UNIX-like OS with separate process contexts as long as virtual memory isn't an issue. >But I still haven't come closer to understanding why people on this newsgroup >hate the Intel processor, when the Intel/Motorola lines are so similar in terms >of performance. Perhaps it's the same reason one might choose a Porsche 944 over a Ford Mustang even though they can go at the same speeds. The Motorola architecture has been very clean all along. The Intel architecture has had ugliness grafted on top of ugliness. Although the modern Intel chips, the '386 and '486, are much closer to their Motorola counterparts in terms of native mode features, there are penalties based on the architectural baggage they're required to carry around. The '386 has 1/2 the machine registers of the '030, and they're less general purpose, and they didn't have room on-chip for any cache memory or split I/D buses. The '486, in order to support the way MS-DOS programs actually run, wasn't free to change any supervisor mode constructs, and it had to settle for a unified cache instead of separate I and D caches to support the self-modifying code used heavily under MS-DOS (the obvious advantage of separate I and D caches is that I and D fetches can occur in parallel, as they do for cache hits on the '030 and '040. Etc.). The Motorola MMU, not having to carry around all the segmentation stuff from previous generations, is a much better match to UNIX than the '386/'486 MMU, even though the Intel MMUs do have a minimal paging mechanism. Most of this doesn't amount to much in reality, right now. C programmers on Motorola machines get more register variables, and UNIX runs a tad more efficiently on an '030 than a '386. On the other hand, in the PC world at least, most of the Intel machines sport external cache, whereas the 680x0 machine at best offer it as an option (out of NeXT, Amiga, Atari, and Apple, only the Apple IIfx comes with external cache). As a follower of this for quite some time, I think the 68040/80486 generation is where the clean architecture of the Motorola line is going to make a very obvious difference in performance, rather than the rather insignificant differences in the '030/'386 generation. >> Tim Onders >-- Jerry Shekhel -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!