Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!bnrgate!bnr-fos!bigsur!bnr-rsc!bcarh185!schow From: schow@bcarh185.bnr.ca (Stanley T.H. Chow) Newsgroups: comp.sys.amiga Subject: Return of the processor wars, part II Message-ID: <1646@bnr-rsc.UUCP> Date: 10 Jan 90 00:11:44 GMT Sender: news@bnr-rsc.UUCP Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) Organization: BNR Ottawa, Canada Lines: 198 Summary: Followup-To: Keywords: Now that everyone is back from Christmas, hopefully I won't get flamed quite so badly :-) Instead of quoting all the articles in detail, I will just respond to the points raised. Given that most of the articles have expired on my news system, I won't try to attribute to specific authors. If you really don't want to read anymore of this, stop now. For your convienence in flaming, I have number my assertions and also the steps in my "proof". Flame by number to save net bandwidth. Please note that I have carefully *not* made any pronouncements on the merit of any of the processors. I am merely commenting on the approaches of dealing with bugs/quirks/... Careful readers will notice that several assertion that I alledgedly made are not here. That is because I did not made them so I feel no obligation to justify them. Specifically, I do *not* claim: ^^^^^ - Any other computer system is better than anything. - Any processor architecture is better than anything. - Bugs should never be fixed. - Violating software guidelines is good pratice. Note that the above list what I do *not* claim. ^^^^^ I am being very clear and repeating what I am not claiming so that even non-careful readers will notice the negations. I do not intend to answer any articles accusing me of any of the above. First of all, let me clarify some terminology: "A processor family": A number of processors that are architecturaly identical and differ only in the implementation details of speed, bus width, etc. Usage: "The MC68020 is object code compatible with the earlier members of the MC68000 Family ..." MC68020 User's Manual, Second Edition "MC68K family": by common usage (and as used by Motorola), this refers to the 68000, '008, '010, '012, '020, '030. (and of course the 68040 when it shows up). "Object Code compatible": This means *all* programs that run on an earlier/smaller/slower/cheaper member of the family will run *unaltered* on later/bigger/faster/more expensive members. There are two levels of compatibility: - User level only, - Blanket (including system & user level). By common usage, in the Unix world, User level is the assumed level. In the PC-Clone world, Blanket is assumed. I assert the following statements: a) MOVE SR is a quirk (or inconsistancy) in the definition of the 68000. b) MOVE SR is a bug in the definition of the 68K family. c) Amiga does not support the 68010. d) The '030 MMU is not upward compatible with the 68851. e) The '851 is a bug in the definition of the 68K family. f) The Intel x86 family is object code compatible. I also hold the following opinions: g) The Intel approach is preferable. h) Motorola should have marketed the 68010 as the replacement for 68000 and defined the 68K family to start with 68010. To take the simplest statement (c) first: 1) A machine base on the 68K family can be made to be Object Code Compatible at the User level. This means the operating system must be changed/patched to handle the MOVE SR case. 2) A stock Amiga equiped with a 68010 is *not* object code compatible at the user level. A patch is required (the famous DeciGel). 3) Commodore-Amiga does not sell the needed patch. There is no offical support for the patch. Therefore, "Amiga does not support the 68010". As to statement (d: '030 MMU is not upward compatible with the 68851): 4) "The following functions of the MC68851 are not available in the MC68030 MMU: Access levels, Breakpoint registers, Root Pointer Table, Aliases for Tasks, Lockable Entries in the ATC, ATC Entries Defined as Shared Globally." Page 9-37 of "MC68030 User's Manual" "In addition, the following features of the MC68030 MMU differ from the MC68020/MC68851 pair: 22-Entry ATC, Reduced Instruction Set, Only Control-Alterable Addressing Modes Supported for MMU Instructions." Page 9-39 I believe this is adequate for me to assert d. As a corollary of d, the extra features of the '851 are not needed but they were defined and implmented. This is at best sub-optimal and I would call it a bug in the 68K family. You may choose to call '030 the bug instead. That covers assertion e. (Onto the *real* flame generators :-) Assertion f states: The Intel x86 family is object code compatible. Again, please note that I made no comments on the relative merits of any system; I am stating my observations of one single facet. 5) I have taken programs written for the XT written before the advent of '286 & '386 and run them on AT and 386-clones. They all run with no problems (except for Video or other hardwares). In fact, the earliest versions of MS-DOS runs on all machines. Furthure, any combination of {program-version, DOS-version} that runs on any machine should run on all machines. 6) I therefore refer to the x86 family as Object Code Compatible. Not only at user level, but Blanket compatibility. As a user, I prefer a system that is object code compatible. Therefore, I prefer the Intel approach. Since g is my opinion, I need only state it, no proof is needed. (Finally, I get around to the assertions that started this whole mess). Assertion a: MOVE SR is a quirk in the definition of the 68000. 7) The 68000 has seperate Superviser & User states. 8) Other instructions needed to virtualize are priviledged. 9) MOVE SR is the only obstacle to virtualize (on the 68000). 10) There is no major reason to keep MOVE SR at user level. Therefore, MOVE SR is a mistake or at best a quirk. Assertion b: MOVE SR is a bug in the definition of the 68K family. 11) The 68K family is supposed to be Object Code Compatible. (See quote in the definitions at the start of this note). 12) Code that runs on the 68000 may not run on the rest of family. Operating system change is required. 13) MOVE SR is the instruction causing this problem. Therefore, MOVE SR is a bug. As to opinion h (68000 should be replace by the 68010), think how much simpler this whole mess would be if Motorola had just admited the mistake and replaced the 68000 with the '010. The whole family would then really be compatible and much nasty code would have been avoided. I also realize that it was politically impossible for Motorola (or anyone else, for that matter) to admit it as a design flaw, they had to sell the '010 as a "Newer, Better Chip" that allows virtual machines. They probably also thought they could price the '010 higher and make more money. Oh well, reality intrudes again. ---------- Feel free to comment on my reasoning. Name calling is not encouraged. Also, please do not blame me for statements that I have not made. In particular, reread the list of things that I did not say. -- 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.