🚀 go-pugleaf

In article <3544@cruzio.santa-cruz.ca.us> aki@cruzio.santa-cruz.ca.us writes:
#
#/**************************************************************************
#   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
#
It's not exactly a bug. 80?86 has a lookahead buffer to read a few
next instructions while the current one is executing. As a result, if
you modify nearby code, CPU may execute the old version from the
buffer. In your case it's CALL 0000:0000, so no wonder computer ends
in hyperspace. The quick fix is jmp $+2 before offending code to
flush the buffer. However, because jmp is rather slow, I usually try
to rearrange code so that instruction is modified long before
execution.

The worst thing is that the size of the lookahead buffer grows from
one CPU to another, so you can end up with code working on 286, but
not 386. 

It took me quite a while to figure this out when I had a simular problem
with my code. Just imagine my surprise when the program worked fine
when I single-stepped through it, but refused to run for serious!

						Oleg Kibirev
						kibirev@CSA.BU.EDU