8088 vs. 80c88

[les at frii.com]

>In emulation mode (V20) BP = (8080) SP.  But I don't follow your
>logic on how to avoid it.  Why JRT chose to code things that way,
>I'll never know, but it worked on 8080, 8085 and Z80 and not on V20,
>so it's a bug.  And a bug in commercial (i.e. you paid money for it)
>software.

The code snippet you showed seemed to indicate that either you couldn't
preform a call to the same address contained in the stack pointer, or that
you couldn't preform a call as the next instruction after a lxi sp
instruction.  Its not really clear which the problem is.  I am assuming
the problem relates to following a lxi sp instruction immediatly with a
call instruction, I can see how pipelining instructions could cause this
failure.   I cant immagine how calling the address which happens to match
the sp would be an issue.

My thought was that most cp/m programs either left the sp alone, and used
the stack provided by cp/m, or set up a local stack early on in the
program.  In either case this bug could be completly avoided.  Am I wrong
here?  Is the bug related to calling the address which happens to be in
the sp?


>The instruction prefetch queue issue was well documented in the 386,
>as was the use of an unconditional jump to void the queue.  Although
>it's lousy practice to use self-modifying code, I don't blame
>MicroPro for it--they wrote their code to an earlier processor.
>But claiming backward compatibility is a different game.  Unless
>something is 100% backward-compatible with the original, you'd best
>not advertise it as being backward-compatible at all, unless you like
>answering support calls.

So as I understand your opinion, if NEC had stated in the V20
documentation, that you should not follow a lxi sp instuction immediatly
with a stack operation, this would not have been a bug.  In the case of
the 386, they documented issues with the 386 queue, issues which crashed
commercial software, but which are not a bug.  In this case, it was just
code written for an older processor.

Les