🚀 go-pugleaf

In article <3544@cruzio.santa-cruz.ca.us> aki@cruzio.santa-cruz.ca.us writes:
}I was going through some of my old files and just happened to find a file
}describing a bug with the 386SX.  This particular problem is _not_ documented
}in any publication I could get my hands on,  so if there is anyone out there
}keeping track of Intel's bugs...  (BTW,  it was a pain to ID this problem,
}since all the debuggers would execute the command correctly.  I imagine
}trapped execution mode prevents the problem).  Description follows:

It's a bug in the code, not in the processor.  In order to guarantee that
self-modifying code will work, you must either flush the prefetch queue
with a branch instruction (JMP, CALL, RET, taken conditional, etc) or locate
the modifying instruction further from the modified instruction than the
size of the prefetch--ranging from 4 bytes on an 8088, 6 on an 8086, to
12 bytes on a 386 and as much as 32 bytes on a 486.

Your code doesn't work when run full-speed because the processor has already
fetched the CALL instruction at the time it is modified.  It works when
single-stepped because the interrupt called after each instruction when
single-stepping flushed the prefetch queue.
-- 
{backbone}!cs.cmu.edu!ralf  ARPA: RALF@CS.CMU.EDU  FIDO: Ralf Brown 1:129/26.1
BITnet: RALF%CS.CMU.EDU@CARNEGIE   AT&Tnet: (412)268-3053 (school)   FAX: ask
DISCLAIMER?  Did   |  Hansen's Library Axiom: The closest library doesn't
I claim something? |                          have the material you need.