Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!bnrgate!bnr-fos!bigsur!bnr-rsc!bcarh185!schow From: schow@bcarh185.bnr.ca (Stanley T.H. Chow) Newsgroups: comp.sys.amiga Subject: Re: Return of the processor wars, part II Message-ID: <1651@bnr-rsc.UUCP> Date: 12 Jan 90 23:32:14 GMT References: <1141@crash.cts.com> Sender: news@bnr-rsc.UUCP Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) Organization: BNR Ottawa, Canada Lines: 97 Summary: Followup-To: Keywords: 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.