schow@bcarh185.bnr.ca (Stanley T.H. Chow) (01/10/90)
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.uzun@pnet01.cts.com (Roger Uzun) (01/11/90)
I have worked extensively with the 8086 and 68000 family
of processors. I prefer the 68000 because of its more regular,
orthogonal instruction set, General Purpose registers,
(Intel Divides for example always go in the AX register),
and superior memory model.
I should point out that I have encountered a lot of code that
runs on an 8088 system and fails miserably on an 80386.
Poorly written software for any specific member of a chip family,
can and does fail.
Examples:
1) A divide error handler on the 8086 that assumes that the CP:IP
points to the instruction AFTEr the one that caused the error,
this code does exist in a program we used to use, it runs
fine on 8086 crashes bigtime when run on an 80386 system
2) an 8087 program that routes all Coprocessor errors through
vector 14 instead of vector 16. The 80386 requires cp errors
to go through vector 16
C= has always REQUIRED programmers to avoid Move SR,EA in
USER MODE. If I defy that direction, my program only runs
BY COINCIDENCE on some amigas, it is a NON AMIGA PROGRAM!
Someone can always write code that does not run on other members
in the same chip family be it INTEL or MOTOROLA at least C=
has warned us not to do it and told us how to avoid it.
THE AMIGA FOR THESE REASONS DOES CATEGORICALLY SUPPORT ALL
680X0 FAMILY MEMBERS, SOME PROGRAMMERS HAVE WRITTEN PROGRAMS
THAT DO NOT, BUT THEY DID SO IN DIRECT VIOLATION OF C= GUIDELINES!
In my personal experience, there are more ways to have an 8088
program fail on an 80386 than there are to have a 68000 program
fail on a 68010. Perhaps if Mr Chow gets around to developing
software, his opinion on which processor is better will change.
-Roger
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.comYTHPRGDB@MTUS5.BITNET (01/11/90)
In article <1646@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: [...] > f) The Intel x86 family is object code compatible. > Question: Are the 286 & 386 object-code compatible in their respective "protected" modes? I got the impression that this only applied to the "real 8086" and "virtual 8086" modes. Many of the neat added abilities of the 286 and 386 (including addressing beyond 1M of memory) are only available in the "protected" modes of operation. IMHO, Intel's mode-based emulation adds just as much complexity as (if not more than) the problems with MOV SR in the 68K family. Granted, Intel did a very nice thing in giving us the "virtual 8086" mode to allow multiple 8086-based programs (DOS-based?) to execute concurrently. This seems to be an excellent idea, but why then does OS/2 only allow one DOS task (in the compatibility box)? [...] >-- >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. > > ------- -- Noel Maddy Bitnet: ythprgdb@mtus5 '...moore input...' Snail: 210 Vivian - Number Johnny Five Hancock, MI 49930
ejkst@unix.cis.pitt.edu (Eric J. Kennedy) (01/12/90)
In article <90010.202827YTHPRGDB@MTUS5.BITNET> YTHPRGDB@MTUS5.BITNET writes: >Granted, Intel did a very nice thing in giving us the "virtual 8086" >mode to allow multiple 8086-based programs (DOS-based?) to execute >concurrently. This seems to be an excellent idea, but why then >does OS/2 only allow one DOS task (in the compatibility box)? Personally, I find the virtual-8086 mode to be a miserable kludge, since its only purpose in life is to make up for the glaring defiencies in a miserable excuse for an operating system that never should have survived past 1984. [Please pardon the outburst. I'm just spend all day fighting dBase IV and MS-DOS tooth and nail, and I can't wait to get home to my Amiga where it doesn't cost me 5 minutes just to consult a text file.] -- Eric Kennedy ejkst@cis.unix.pitt.edu
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (01/13/90)
In article <1141@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes: > [Very good reasons for prefering 68K over x86 architecure. SC] Good. But this is irrelevant to the present discussion of how to handle bugs in processors. >I should point out that I have encountered a lot of code that >runs on an 8088 system and fails miserably on an 80386. >Poorly written software for any specific member of a chip family, >can and does fail. >Examples: >1) A divide error handler on the 8086 that assumes that the CP:IP >points to the instruction AFTEr the one that caused the error, >this code does exist in a program we used to use, it runs >fine on 8086 crashes bigtime when run on an 80386 system >2) an 8087 program that routes all Coprocessor errors through >vector 14 instead of vector 16. The 80386 requires cp errors >to go through vector 16 > Ah, facts that actually address the question! I would say you have found an incompatibility between the 8086 and the 80386 - at least at the system level. This means Intel should only claim User-level compatibility or they better admit a bug. According to "80386 Programmer's Reference Manual" section 15.6, there are 16 difference between the real 8086 and the virtual-86 in the 386. Yes, really, sixteen differences. BTW, you found numbers 2 & 14. "The purpose of a V86 task is to form a 'virtual machine' with which to execute an 8086 program. A complete virtual machine consists not only of 80386 hardware but also of system software. Thus the emulation of an 8086 is the result of cooperation between hardware and software: - The hardware provides a virtual set of registers (via the TSS), a virtual memory space (the first megabyte of the linear address space of the task), and directly executes all instructions that deal with these registers and with this address space. - The software that controls the external interfaces of the virtual machine (I/O, interrupts, and exceptions) in a manner consistent with the larger environment in which it executes. In the case of I/O, software can choose either to emulate I/O instructions of to let the hardware execute them directly without software intervention." Page 15-1 of the 386 reference manual. This sounds like a very long-winded way of claiming User level compatibility. (I knew starting a flame war was useful! I finally got around to reading the 386 manual after all these years. Now I can even claim Usenet is useful on the job :-) >C= has always REQUIRED programmers to avoid Move SR,EA in >USER MODE. If I defy that direction, my program only runs >BY COINCIDENCE on some amigas, it is a NON AMIGA PROGRAM! I agree it is extreme poor practice for developers to ignore guidelines issued by the computer manufacturer. So, how does that affect the question at hand? Actually, you would have a much stronger case if Commodore did not list these programs in its list of Amiga programs and if the computer stores stocked them in the "NON AMIGA PROGRAM" section istead of the "Amiga" section. What I am saying is observe reality. The mess (okay, it is only a small mess as messes go) is directly a result of the MOVE SR bug. >Someone can always write code that does not run on other members >in the same chip family be it INTEL or MOTOROLA at least C= >has warned us not to do it and told us how to avoid it. >THE AMIGA FOR THESE REASONS DOES CATEGORICALLY SUPPORT ALL >680X0 FAMILY MEMBERS, SOME PROGRAMMERS HAVE WRITTEN PROGRAMS >THAT DO NOT, BUT THEY DID SO IN DIRECT VIOLATION OF C= GUIDELINES! You know, you are one in a long line of people that have told me this. Perhaps you should check with Commodore-Amiga first. Tell me one program that C-A gurantees to run on the '010. As far as I know, C-A does not even gurantee that workbench will come up. Just think, you are accusing C-A of piss poor support! 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.
valentin@cbmvax.commodore.com (Valentin Pepelea) (01/13/90)
In article <1651@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes: > >>THE AMIGA FOR THESE REASONS DOES CATEGORICALLY SUPPORT ALL >>680X0 FAMILY MEMBERS, SOME PROGRAMMERS HAVE WRITTEN PROGRAMS >>THAT DO NOT, BUT THEY DID SO IN DIRECT VIOLATION OF C= GUIDELINES! > >You know, you are one in a long line of people that have told me >this. Perhaps you should check with Commodore-Amiga first. Tell >me one program that C-A gurantees to run on the '010. As far as >I know, C-A does not even gurantee that workbench will come up. Well, as my .signature states, I am not a CBM spokesman and do not claim to be, but Workbench certainly is guaranteed to run on all 680x0 processors, as well as the OS. I fear that your comprehension of the MOVE SR,<ea> instruction along with all its implications is still eluding you. Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
schow@bcarh185.bnr.ca (Stanley T.H. Chow) (01/14/90)
In article <90010.202827YTHPRGDB@MTUS5.BITNET> YTHPRGDB@MTUS5.BITNET writes: >In article <1646@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) says: >[...] >> f) The Intel x86 family is object code compatible. >> > >Question: Are the 286 & 386 object-code compatible in their >respective "protected" modes? I got the impression that this >only applied to the "real 8086" and "virtual 8086" modes. As far as I know, the 386 protected mode is a superset of the 286 protected mode. (But then, I only read the 386 book for the first time yesterday). > >Many of the neat added abilities of the 286 and >386 (including addressing beyond 1M of memory) are only available >in the "protected" modes of operation. IMHO, Intel's mode-based >emulation adds just as much complexity as (if not more than) the >problems with MOV SR in the 68K family. > You know, this is the second follow-up that actually has facts instead of How-dare-you-slander-Amiga/Motorola. Quite possible. Since I have done no programming on x86 machine (okay, I actually did write one little C program), I don't know. The question is: whose problem is it? The OS writer? The application writer? Or the User? It seems to me the mode switch stuff is mostly in the OS and some in the application, so as a user, I am happy. As a programmer, I would probably grummble, but since I can keep the user happy, I as the programmer would probably be happy too. >Granted, Intel did a very nice thing in giving us the "virtual 8086" >mode to allow multiple 8086-based programs (DOS-based?) to execute >concurrently. This seems to be an excellent idea, but why then >does OS/2 only allow one DOS task (in the compatibility box)? I assume this is a limitation of OS/2 that is designed to force users to migrate to "true" OS/2 applications. Since this is getting away from Amiga, I have redirected the follow-up to comp.sys.ibm.pc. 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.
peterson@FSUCS.CS.FSU.EDU (Eric J. Peterson) (01/14/90)
In article <1652@bnr-rsc.UUCP>: | In article <90010.202827YTHPRGDB@MTUS5.BITNET> YTHPRGDB@MTUS5.BITNET writes: | >Granted, Intel did a very nice thing in giving us the "virtual 8086" | >mode to allow multiple 8086-based programs (DOS-based?) to execute | >concurrently. This seems to be an excellent idea, but why then | >does OS/2 only allow one DOS task (in the compatibility box)? | | I assume this is a limitation of OS/2 that is designed to force users | to migrate to "true" OS/2 applications. DISCLAIMER: I know virutally nothing about OS/2. What follows is speculation only. More likely, this limitation is due to the inability of DOS to multitask (without packages such as ConcurrentDOS and DoubleDOS). DOS does not have any way to lock resources to individual processes the way that a multitasking OS does. This paves the way to race conditions and all sorts of classical Op sys problems. Suppose OS/2 supported multiple Compatibility Boxes. Suppose that an application in one Box configures and uses the serial port. Suppose that another Box tries to access and configure the same port. When it changed any of the port settings, one or both programs would crash or operate erroneously. Of course, Microsoft could have added resource sharing controls to its Compatibility Boxes. But this has the potential to introduce compatibility problems; i.e., using a Compatibility Box-compatible program in one Box while using a non-compliant program in another. But if you're adding all of these things, why not just make it into a new spectacular version on DOS? Two reasons as far as I can tell: (1) Development Time. It's easier to implement something that already exists than it is to go out and make something new from scratch. The important thing was getting OS/2 out on the market. (2) Lack of Necessity. DOS 4.0 has all sorts of great new features in it, yet the public has virtually ignored it. Plus, if you're going to do things in DOS such as resource locking and so forth, why not just use OS/2? Followups directed to comp.sys.ibm.pc. Eric -- . |~~ _O_) Eric J. Peterson ... peterson@{nu,fsucs}.cs.fsu.edu ( X FSU CS Technician // 011 Love // Work: 904-644-2296 // Home: 904-576-3318 _/ \_ echo "This is not a pipe." | lpr -P laserwriter