Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ns-mx!umaxc.weeg.uiowa.edu!williams
From: williams@umaxc.weeg.uiowa.edu (Kent Williams)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: v09i191: popadbug, test for 386 CPU bug
Message-ID: <3825@ns-mx.uiowa.edu>
Date: 8 Jan 91 22:12:39 GMT
References: <336@aplcomm.JHUAPL.EDU> <1991Jan5.000042.19703@cunixf.cc.columbia.edu> <1991Jan5.044926.14501@eng.ufl.edu> <1991Jan5.223646.29894@menudo.uh.edu> <1991Jan8.040941.5797@monu6.cc.monash.edu.au> <6952@suned1.Nswses.Navy.MIL>
Sender: news@ns-mx.uiowa.edu
Reply-To: williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams)
Organization: U of Iowa, Iowa City, IA
Lines: 24


OK ENOUGH!

I have looked at Jeff Prothero's dos extender source.  In it there is one
place where he puts a NOP after a POPAD, and comments that it is a workaround
for the POPAD bug.  Elsewhere in this huge assembly code file there are
comments on other 386 bugs.  NOWHERE does he say that he 'discovered' the
POPAD bug, and I've seen no proof from anyone that it is, in fact, a newly
discovered animal, OR that it is serious, OR that the people who write
extended applications like Windows 3.0 aren't aware of it.

If you're a big-time developer, and Microsoft is as big as they come, you're
into Intel's pants deep enough that you get all the bug sheets.

So guys, stop spazzing out.  If you want to POPAD, put a NOP after it, and stop
acting like the sky is falling!

BTW, when I run the test program, my 386sx fails.  If I run it under a debugger
it works, since the next instruction after the POPAD is the trap back to the
debugger.
--
             Kent Williams --- williams@umaxc.weeg.uiowa.edu 
"'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams"
"This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"