openMSX/doc/internal/r800-call.txt

Some time ago (March 2015) Laurens Holst (aka Grauw) did some measurements
on the duration of various R800 instructions. For his results see
   http://map.grauw.nl/resources/z80instr.php
For the most part he was able to confirm the results we obtained earlier
(described in the "r800test.txt" document). Though for the CALL
instruction he 'sometimes' got a 1 cycle difference. Now, half a year
later, I finally got around to investigate this in more detail.


I used the following measuring method. Alex Wulms once created an MSX
cartridge with a 3.57MHz counter on it. Writing to IO port 0x20 resets the
counter and reading from IO ports 0x20-0x23 (atomically) reads it. So this
is much like the MSX-turboR E6-timer, except that it ticks 14x faster. The
R800 runs at 2 x 3.57MHz, so that means we can still only measure up-to 2
cycles accurate. To work around this I always repeat the to-be-measured
sequence twice. Here's an example program.

	org #c000

	di
	out (#20),a   ; reset timer

	call func     ; repeat to be measured
	call func     ;   sequence twice

	in a,(#20)    ; read timer
	ld l,a
	in a,(#20)
	ld h,a
	ret

func:	ret

Initially I run this program without the 2 'call func' instructions. After
the program returns, register HL contains the value '5'. This is the
time between reseting and reading the counter. This value should be
subtracted from all future measurements.

Note: usually these test programs give stable results. But once in a while
you get a too high value. This can be explained by the R800 refresh stuff
(see "r800-refresh.txt" for more details). By repeating the same test a
few times it's often possible to avoid this refresh stuff.

When re-inserting the two 'call func' instructions, I obtain the value
'17', subtracting 5 gives 12. So executing 2 'call + ret' sequences takes
2x12 cycles. So a single 'call + ret' sequence takes 12 cycles. Later in
this text I won't repeat this calculation, I'll directly give the length
of the (single) sequence.

So this confirms the result of my earlier measurements. See "r800test.txt"
for details. There I also show that these 12 cycles decompose into 7
cycles for the "call" instruction and 5 cycles for the "ret" instruction.

The interesting thing is that Laurens 'sometimes' measured 8 cycles for
the "call" instruction. Let's now make the following change in the program:
	...
func:	nop     ; <-- added this nop instruction
	ret

So the executed sequence is now "call + nop + ret". Naively we'd expect
this to take only 1 cycle more. Instead we measure 14 cycles (2 more).

I also tested this program:
	...
	call func
	nop
	call func
	nop
	...
func:	ret

The sequence is now "call + ret + nop". This does take 13 cycles (only 1
more). So it's really "call" immediately followed by "ret" that is
special.

I measured a lot of other sequences as well. I'll summarize them in this
table:

   sequence            measured  decomposed  remark
a) call, ret               12    7+5         NO penalty, call-ret is special
b) call, ret, nop          13    7+5+1       NO penalty

c) call, nop, ret          14    7+3+4       penalty on nop
d) call, nop, nop, ret     15    7+3+1+4     penalty on 1st nop

e) call, reti              15    7+8         penalty on reti, reti is NOT special
f) call, nop, reti         16    7+3+6       penalty on nop

g) call, pop hl            12    7+5         NO penalty, call-pop is special
h) call, nop, pop hl       14    7+3+4       penalty on nop
i) call, nop, nop, pop hl  15    7+3+1+4     penalty on 1st nop

j) call, pop ix            14    7+7         penalty on "pop ix", different from "pop hl"!
k) call, nop, pop ix       15    7+3+5       penalty on nop
l) call, nop, nop, pop ix  16    7+3+1+5     penalty on 1st nop

m) push hl, pop hl         11    6+5         no penalty,
n) push hl, nop, pop hl    12    6+2+4          push-pop is not special
o) push hl, ret            11    6+5         no penalty,
p) push hl, nop, ret       12    6+2+4          push-ret is not special

q) rst, ret                11    6+5         NO penalty, rst-ret is special
r) rst, nop, ret           13    6+3+4       penalty on nop
s) rst, nop, nop, ret      14    6+3+1+4     penalty on 1st nop

t) rst, reti               14    6+8         penalty on reti, reti is NOT special
u) rst, nop, reti          15    6+3+6       penalty on nop
v) rst, nop, nop, reti     16    6+3+1+6     penalty on 1st nop

w) rst, jp(hl)              9    6+3         penalty on jp(hl)
x) rst, jp(ix)             10    6+4         penalty on jp(ix)


Details:

a) For simplicity I've shown the decomposition 12 -> 7+5. In reality the
situation is more complex. The full sequence in the test-program is
  out ; call ; ret ; call ; ret ; in

When we take page-breaks into account, we get the following for the 4
middle instructions (I'm using the notation from the "r800test.txt"
document):
   fffWw FRr FffWw FRr + page-break
So the 1st "call" instruction takes 6 cycles, the 1st "ret" takes 5
cycles, 2nd "call" takes 7, 2nd "ret" takes 5 and the next "in"
instruction has a page-break-penalty on fetch. If we simplify this
(artificially attribute the page-break for "in" to the 1st "call") we can
say "call" takes 7 and "ret" takes 5 cycles.

Notice that there's an even number of cycles between the "out" and "in"
operation. So this inserts an IO-penalty on the IN instruction (to align
the R800 bus at 7MHZ to the external cartridge bus at 3.5MHz, see
"r800test.txt" for more details). In case of an empty sequence ("out"
directly followed by "in"), we have zero cycles which is also even. So our
calibration method (subtract 5 from the measured result) remains valid.


d) I'll give another example of the simplified decomposition. The full
sequence is:
  (out) ; call ; nop ; nop ; ret ; call ; nop ; nop ; ret ; (in)
The middle part (without out-in) decomposes to
  fffWw Fx f fRr FffWw Fx f fWw + page-break
    6   3  1  4    7   3  1  4    (+1)
Here 'x' is an extra "call-penalty", see below for more details. So if we
artificially move the page-break-penalty for "in" to the front we get
7+3+1+4 for call+nop+nop+ret. This same simplification is made for all
decompositions in the table.


c) Compared to 'a' you'd expect this sequence to take only 1 extra cycle
(just like sequence b). Instead there's yet 1 more extra cycle. In
general, when looking at more sequences and/or replacing 'nop' with other
instructions with known duration (not shown in the table), we see that we
always get an extra cycle whenever a call instruction is not _immediately_
followed by a "ret" or "pop" instruction. We'll call this a "call-penalty"
cycle.

We could attribute this call-penalty cycle to the call instruction itself,
thus say that the call instruction takes 7 or 8 cycles, depending on what
instruction follows. For most practical purposes this explanation is good
enough. Though if you look in detail, the fetch of the next instruction
has to start 7 (not 8) cycles after the start of the call instruction
(otherwise we cannot know whether there should be a penalty or not). So
this call-penalty really happens during the _next_ instruction.

   It's likely that this call-penalty stuff can be explained in a simpler
   way if you look at the full-pipelined implementation of the R800.
   _Maybe_ a call somehow/sometimes introduces a late pipeline stall.
   Though because no details are known about the R800 pipeline, for now,
   I'll stick to this weird sequential explanation that a "call"
   instruction somehow induces a stall in the next instruction.


e) In sequence 'a' and 'b' we saw that "call" immediately followed by
"ret" has no call-penalty. This is _not_ the case for "reti" or "retn".


g) h) i) A "call" immediately followed by "pop" also has no penalty.

j) k) l) Though "pop" has to be a single-byte instruction ("pop af", "pop
bc", "pop de" or "pop hl"). "pop ix" or "pop iy" do have the call-penalty.
This is similar to how a multi-byte return instruction (reti) also gets
the penalty.


m) n) o) p) From a stack-usage point of view a "call" immediately followed
by a "ret" or "pop" is similar to a "push" immediately followed by "ret"
or "pop". Though the tests show there's no penalty for push-nop-pop
compared to push-pop or for push-nop-ret compared to push-ret.

q) r) s) t) u) v) The "rst" instruction behaves similar to "call", so
there is a penalty on the next instruction except if that next instruction
is a (single-byte) "ret" or "pop". The only difference is that the "rst"
instruction itself takes 1 (only 1!) cycles less than a "call"
instruction.



TODO implement this stuff in openMSX.