Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!batcomputer!riley From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley) Newsgroups: comp.sys.amiga Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!) Message-ID: <9475@batcomputer.tn.cornell.edu> Date: 24 Dec 89 15:15:39 GMT References: <1624@bnr-rsc.UUCP> <9140@cbmvax.commodore.com> <1626@bnr-rsc.UUCP> Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 81 In article <1626@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: >In article <9140@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>[...] 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! > >Thanks Dave, so nice to have my point confirmed by a real expert. > >The original discussion was on bug-lists for different micro-processors. >Someone asked for bugs on the 68K side and I pointed out the MOVESR as an >example. "Bug" and "design flaw" are not the same thing. MOVE SR on the 68000 behaves the way it was designed to--therefore, it is *not* a bug. It does mean that the 68000 can't be virtualized, which could be considered to be a "design flaw", depending on your application and interests. >Please note that I have nothing against fixes (or any changes). I just think >there are better times and worse times for making them. E.g., if the '010 >was/is intended as replacement for the '000 and the change is painless, >then Motorola should just drop the '000 all together. The fact the Motorola >still sells mostly '000 means either people think the change is hard or >that the people think the change is not worth it. Case in point - Amiga >after 4 release still does not support it. The '10 was not intended as a replacement for the 68000. It was intended to be a 68XXX family processor which could support virtual memory and page fault interrupts, and could be virtualized. Those are important features for workstation manufacturers, so presumably Motorola wanted a 68XXX family processor with those feature available before it finished the 68020, and it wanted to have a low-end 68XXX family processor with those features available after the 68020 was released. Motorola still sells mostly 68000 because most micros don't need virtual memory, page fault interrupts and virtualization (yet), and workstation vendors have mostly switched to the '20 and '30. You're missing the point by locking yourself into the view that the '10 had to be an upgrade to the 68000 for every application, when this just isn't so--it provided some important features, but not everyone needs those features. If they don't need those features, they use the cheaper 68000. I don't understand your comment that the Amiga doesn't "support" the 68010. The Amiga works fine with a 68010. Some software which violates Commodore's explicit guidelines for Amiga software does not work with a 68010. Some software which violates Commore's guidelines does not work with later releases of the operating system, or different memory or hardware configurations. This doesn't mean that the Amiga doesn't support the 68010, any more than it means the Amiga doesn't support later releases of its own operating system. It does mean that some developers wrote broken software. If you mean that the Amiga doesn't use the extra features of the 68010 (yet), sure, that's true. That doesn't mean the 68010 isn't supported. >>> 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. > >Perhaps Dave needs to talk to Keith. :-) > >In artivle <668@bmers58.UUCP>, Keith Hanlan writes: >> See Dave Haynie's earlier >>comments on this. If you really need it - which most will contend you >>don't - add the '851 anyways. No, Keith needs to talk to Dave. >The point is: "If it ain't broke, don't fix it". > >The real point is: "If it is broke, but nobody cares, don't fix it anyway". And we're telling you that people care. -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University