24 Feb
2009
24 Feb
'09
10:27 a.m.
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