Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!bnrgate!bnr-fos!bigsur!bnr-rsc!bcarh185!schow From: schow@bcarh185.bnr.ca (Stanley T.H. Chow) Newsgroups: comp.sys.amiga Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!) Message-ID: <1626@bnr-rsc.UUCP> Date: 23 Dec 89 08:37:09 GMT References: <1624@bnr-rsc.UUCP> <9140@cbmvax.commodore.com> Sender: news@bnr-rsc.UUCP Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) Organization: BNR Ottawa, Canada Lines: 123 Summary: Followup-To: Keywords: In article <9140@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >in article <1624@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: > >> For example, are you happy that the MOVESR instruction is priviledged on >> the '010? > >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! 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. 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. Yes, I know the '010 is priced much higher, but it had a very short marketing window and was essentially replace by the '020. It would have been much more sensible to fix all the problems in the '020 since the software kernal had to change anyway. > >> 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. Dave, why do you consider the operating system to be non-software? Surely, of all people, you ought to know the expense in making a change like that to an operating system! The point is not whether the two MMU's are individually good enough. The point is also not whether the O/S can hide the difference. The point is that they are different! > >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. Why do you think they *had* to make it compatible? It happens to be good business to protect the user's software investment. Do you think the '286 & '386 clones would have been so popular so quickly if everyone had to buy new versions or had to install interrupt interceptors that may-be sometimes work? I have no intention of defending *any* processor family so I won't get into that line of discussion. >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. Does this have anything to do with MOVESR? Are you saying MOVESR causes occasional crashes? I would have put it into the annoying design-flaw catagory. :-) You are talking an interesting situation, but unrelated to the topic of discussion. A closer analogy is a software package that works correctly with an update that introduces new features. > >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. As I said, the closer analogy is that the new package still works correctly for the old files, but for new files, it has new features. Wait a minute, I seem to remember this being done for some successful packages. > >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. > My version says the update broke the old way of doing things needlessly for new features that a user does not want. 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". 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.