Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!mips!apple!oliveb!amiga!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!) Message-ID: <9140@cbmvax.commodore.com> Date: 22 Dec 89 17:22:31 GMT References: <1624@bnr-rsc.UUCP> Organization: Commodore, West Chester, PA Lines: 83 in article <1624@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: > Summary: > Followup-To: > Keywords: > For example, are you happy that the MOVESR instruction is priviledged on > the '010? Yes, actually, since it's completely painless in any reasonable operating system. > What did this change buy us? The *conceptual* ability to virtualize a '010! > Whoppie. How many people do you know run virtual '010? If there's one, that's more than used a similar capability in the Intel system at the time. But Intel users saved a few byte of memory 'cause they didn't have a trap to install and didn't have an operating system to get between them and the raw hardware. But enough of that nonsense; MOVE SR doesn't amount to a hill of beans. > How many simply use the '010 as a faster '000? Not many. Some folks will do anything for a 5%-10% increase, as witnessed by the Mac II -> Mac IIx upgrades. But the main reason for the 68010 was real support for virtual memory. Every Sun 2 owner benefitted from this, as well as the owners of AT&T UNIX PCs and Tektronics lab computers. If you didn't need the virtual memory, you could stick with the 68000. Your argument can very easily be switched around. I could make the claim that the 68010 was the perfect upgrade for the 68000. It fixes that silly MOVE SR design flaw, so that your 68000 machine can be made user-mode compatible with all 68020,30, and 40 machines for years to come. And the damn thing's even pin compatible. What more could you ask! > This is what I call a bug in the "Family Architecture": put an MMU into > the CPU just so that you can disable it and add an off-chip MMU. Brillant > use of the silicon real estate. No one ever does that. No one. There's no reason to. If you keep insisting there is, you're confused and probably bound to stay that way. This is an implementation detail known only by the operating system. It will not effect a single piece of user software. If you want to consider a bug in the family architecture, consider what you're losing with Intel architecture in having to have complete hardware emulators of the 8086 and 80286 in every '386 and '486 chip. If that space hadn't been wasted supporting architectural hair from the past, it could have been used for something truely useful. When they designed the '386 native mode, they had to cripple it with too few registers, no cache, and a weak MMU to make room for that stuff. Not to mention missing addressing modes. They really cleaned up the architecture of the '386 mode so that most folks don't complain and so that they didn't have to add yet another incompatible mode for the '486. Your claim that the bugs should be maintained really loses when you apply it elsewhere. For example, software. You bug a new software package for your computer, and use it pretty heavily. It has a bug here and there, occasionally crashes, but it's still quite useful. Then the company announces an update. An Intel-style update would give you a new program with two modes. The compatibility mode would read your hundreds of man-years worth of files for this wonder-program, but it would still crash and do anything else nasty the old one did. And it wouldn't offer any new features. The new mode would have all kinds of bug fixes and other goodies, but it wouldn't read any of your old files. The Motorola-style update would add the new features on top of the old, and fix the bugs. You'd be able to read most of your old applications into the new mode of the program, and they'd be immediately able to take advantage of the new features. There might be a few old-style files it wouldn't read directly, but a thoughtfully provided patch program (called, for some unknown reason, "DeciGel") would fix up the old files so that they worked just fine on the new program. > Stanley Chow BitNet: schow@BNR.CA > BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow > (613) 763-2831 ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185 > Me? Represent other people? Don't make them laugh so hard. -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough