🚀 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:
> 
> /************************************************************************
>   The followning INLINE code turned up a _BUG_ in the Intel 386 SX 16 MHz
>   ***********************************************************************/
>  
> /**************************************************************************
>    When the CPU gets to CALLing the hardcoded addr, it will not return.
>    It gets lost in never never land. It seems,  that the address is not
>    correctly stored to the target memory location with the MOV command.
>  
>    I solved the problem by adding some NOP statements between the MOV and
>    the CALL.
>  
>    Aki Korhonen, January 5th, 1992.
>  
>    PS. Check out PC-BENCH 1.4 and the soon-to-be-released PC-DIAG!
> ***************************************************************************/
>  
>   asm     mov ax, segm
>   asm     mov bx, 0
>   asm     mov di, offset offs_tavu
>   asm     mov cs:[di], bx
>   asm     inc di
>   asm     inc di
>   asm     mov cs:[di], ax
>  
>   asm     db 0x9A        /* CALL FAR, next two words are: OFFS, SEGM */
>   asm    offs_tavu:
>   asm     dw 0
>   asm     dw 0
> 
> 
> Aki.
> 
> PS.  I know the code looks terrible,  and don't ask me why I didn't use
> far pointers.  I always work worst after 3 AM.
> -- 
> /  Phone: 408-662 9664 Fax: 662 9676  |  "Aki" pronounced: Ah-Key. I know  \ 
> \  GENIE: A.KORHONEN  Home: /dev/nul  |  what I'm doing most of the time.  /

It's not a bug. 386 SX has a prefetch queue. I don't know the 
exact length of the queue but on 386 DX it is 16 bytes, so I would guess
that it's 16 bytes also on SX. The processor has already fetched the call
instruction when the code modifies itself, so the processor doesn't see
the modification.

The problem doesn't occur if there is at least 16 bytes between the MOV
and the CALL, so adding some NOP:s helps (at least on 386).


Osmo.