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
25 Feb
25 Feb
10:03 a.m.
On 24 Feb 2009 at 11:27, les at frii.com wrote:
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.
As far as we could determine, it was precisely the issue.
uP operation can be mysterious I recall using early (pre-production)
steppings of the 80186 and discovering that under certain
circumstances a DMA transfer wouild clobber SI and DI (that one took
almost 3 weeks to track down).
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?
Again, yes.
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.
Probably not a bug, but definitely a factor in determining if I
should have bothered to use the V20/30 for emulation at all.
Certainly, I wondered if the lack of Z80 instruction set support
would have been an issue. It was--and I supplied a software emulator
for that. Fortunately, I also included an software 8080 emulator, so
even users of JRT Pascal weren't left hanging.
To clarify my point, would you try to run CP/M on a Rabbit uC with
all of its "we're just like a Z80 except when we're not" instruction
set? I've never tried, as the compatibility issues are just too
severe.
Cheers,
Chuck
5778
days inactive
5779
days old
1 comments
2 participants
participants (2)
-
cclist＠sydex.com -
les＠frii.com