Path: utzoo!utgpu!cunews!bnrgate!bwdls61.bnr.ca!bwdls58!mlord
From: mlord@bwdls58.bnr.ca (Mark Lord)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: v09i191: popadbug, test for 386 CPU bug (part 01/01)
Message-ID: <5164@bwdls58.UUCP>
Date: 4 Jan 91 14:39:28 GMT
References: <336@aplcomm.JHUAPL.EDU> <19130@hydra.gatech.EDU>
Sender: mlord@bwdls58.UUCP
Reply-To: mlord@bwdls58.bnr.ca (Mark Lord)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 28

In article <...> bb16@prism.gatech.EDU (Scott Bostater) writes:
<
<We've run it on several 386's where I work and it fails on all of them.  It has
<not failed on the one 486 that we have.  I haven't yet tried it on a 386sx 
<(anybody out there with a SX tried it??).  It also shows up in both of the
<Sun 386i's that I have access to.

It also fails on my 386sx-16.

<As far as ramifications of this bug, I personnally don't think its too major
<of a problem unless you want to program assembly code.  In that case you'll 
<just have to remember to add the NOP after the POPAD command.  When programming
<in 286 assembly language I have had little reason to use the POPA command
<since I hardly ever need to push/pop ALL the registers. Its normally faster to 
<push/pop just the required registers. There would be even less justification to
<push/pop all of the 32-bit registers.  Since there has been a moderate amount
<of 32-bit code produced by now and this is the first that the bug has shown up,
<I don't think the POPAD command is getting used. 

Hmmm.  So if it shows up anywhere, it'll be in windows3, os/2, Qemm386,
and perhaps other 32-bit operating environments..  Might even explain the
occaisional mysterious crashes seen in all of these.  Not likely, though.

-- 
 ___Mark S. Lord__________________________________________
| ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) |
| MLORD@BNR.CA   Ottawa, Ontario | Personal views only.   |
|________________________________|________________________|