Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!sdsu!crash!pnet01!uzun
From: uzun@pnet01.cts.com (Roger Uzun)
Newsgroups: comp.sys.amiga
Subject: Re: Return of the processor wars, part II
Message-ID: <1141@crash.cts.com>
Date: 10 Jan 90 17:36:01 GMT
Sender: root@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 38

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.com