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

I don't think this is a bug.  I have found this 'problem' with the 486.
I think the problem is due to instruction prefetching, aka pipelining.
The processor prefetches instructions during cycles which would not
otherwise cause a bus access, and stores them in a queue (the prefetch
queue).  The processor is using cycles which would have been wasted, to
save cycles later on.
Unfortunately, the prefetch queue is not integrated with the memory
accessing logic (the way the cache is), therefore modifying data in
memory will not cause the data in the prefetch queue to be updated.
Thus the processor will use whatever values were already in the
memory locations.
This is one reason why self-modifying code should be avoided.
There are two ways to get around this problem - either put an instruction
JMP SHORT $+2 between setting up the address and using it - this causes the
prefetch queue to be flushed, or don't self-modify the code.  You could do
some direct stack manipulation and 'RET' to the routine.

Kris
--
"My motto is, you can't fight City Hall. But you can crap on the steps and
then run like mad" - Alexei Sayle
-- 
Kris.Heidenstrom@bbs.actrix.gen.nz  Box 27-103, Wellington, New Zealand