🚀 go-pugleaf

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.  /