Reference measurement differences

[lgblgblgb]

Thanks to @ki-bo we have some measurements of needed opcode cycles to be executed on MEGA65. Since I opted for different method to measure (mainly because Xemu's precision is not enough for that method), first, I wanted to know that my method gives the same values as his ones. The preliminary tests shows, that mostly it does (which is satisfying) however there are interesting differences I can't explain. Since most of the tests are OK and the method is really the same for all opcodes, I cannot simply explain this with my method, at least not easily. To be precise, I have all opcode tests (all MEGA65 opcodes, so of course all the ones from @ki-bo as well), and only 6 differs.

Though I am not ready yet to have all the opcodes tested what he did (and for sure, my goal is to test all opcodes), so far the differences (ref = @ki-bo's result, my = my measurement with megacyc):

ext	opcode	asm	my	ref	result
$00	$21	AND ($nn,X)	7	8	MISMATCH
$00	$31	AND ($nn),Y	7	8	MISMATCH
$00	$32	AND ($nn),Z	7	8	MISMATCH
$00	$82	STA ($nn,SP),Y	42	7	MISMATCH
$02	$B2	LDA [$nn],Z	13	10	MISMATCH
$00	$E2	LDA ($nn,SP),Y	58	8	MISMATCH

Interesting that with addressing mode ($nn,X), ($nn),Y and ($nn),Z I have got different results (faster by one cycle).

UPDATE: there were false alarms here before: with INQ $nn @ki-bo mentioned below (#1 (comment)) this is a non-issue.

UPDATE: with newer MEGA65-core the RTS #$nn issue gone away as well.

UPDATE: the "SP" based ones are radically different! No idea what happens here. Now, I have all MEGA65 opcodes (hopefully ... I've already found one bug to mis-label one ...)

[ki-bo]

The INQ $nn mismatch I can explain. I just did the measurement of that opcode again and noticed that it indeed shows 11 on screen, but I did a mistake taking over that number to my notes, as the number shown on screen is in hex... So, 17 seems to be correct and matches with my measurements.

The mismatch for the AND opcodes I can't explain, yet. I redid the measurements and again get 8 cycles.

[lgblgblgb]

@ki-bo Can you test a larger sample with your method? Ie not only one opcode. I am really curious now, what causes the difference.

TEST_AREA:
        [here is the test payload, usually a single opcode to test]
        INW     loop_counter    ; the idea here that 16 bit should be enough for even an empty loop tested for a video frame
        LDA     Z:wait_for_this_frame
        CMP     FRAME_COUNTER_REG
        test_loop_tail_beq = * + 1
        BEQ     test_loop_tail  ; this must be adjusted by the code to point to TEST_AREA

What I do basically to run this for exactly one frame. So then 810000/loop_counter should give me the cycles the whole loop has (the magic number is the number of cycles within a frame, when in PAL mode). I also test with "empty payload", so I know what number of cycles the test loop requires, I subtract that from every result to get only the payload.

My only hope now to resolve this strange issue if your method may able to show something strange too, if tested this way. Maybe no need to wait a frame as your method is not based on that, but adding similar opcodes as well as I do. My only faint and lame explanation of the problem, that MEGA65 does strange thing when certain types of opcodes "combined" and does not result in simple the sum of opcode cycles ...

Also as I mentioned in PM, there is an interesting problem with RTI testing it seems, pending IRQ can "leak in" even when SEI was used everywhere (including on the stack which RTI pulls into the flags register). Also that seems to be not consistent, only sometimes hit. I assume that can be sign of a core bug, not sure ... I opted out not using SEI to disable interrupts while testing but telling VIC to stop generating IRQs, now I can test RTI reliable as well, no MEGA65 crash anymore. [UPDATE: it was a bug of mine ...]

Also edited the first post in this issue with the new results.

I think, it shouldn't matter, but worth to mention: I use non-standard page (ie not 1 and 0) for stack and zero, I wouldn't think it makes any difference though.

[lgblgblgb]

... or at least if you can test two LDA ($nn,SP),Y opcodes at once, to see, if you have the result being doubled of one (which should be of course). I played now a bit, and I get very confusing result. LDA ($nn,SP),Y seems to take 58 cycles, two of tem 98 cycles. So even not doubled ... If I add another, +40 cycles. if I drop in some CLVs just for fun, no change until 27 CLVs added ... (I mean, the LDA stuff if kept). Checking out the VHDL source of mega65-core, there is tons of "cache flushing" and similar stuffs when M_InnSPY is used. Is it possible that really I measure the truth here, that MEGA65 needs to wait after this opcode? So even if it only takes few cycles, before the next code to execute, there are dozens of "dead cycles"? Things like this:

              if cache_flushing = '1' or reg_addressingmode = M_InnSPY then
                                        -- Don't use cache if flushing or for the stack-relative instructions
                                        -- (at least until we work out the correct formula for the
                                        -- InnSPY access -- it should be quite possibe)
                cache_read_valid <= '0';

In gs4510.vhdl ... That's why it would be great if you can measure two LDA ($nn,SP),Y opcodes "as one". If it's really just 8, two of them will be measured as 16. If there is some magic in VHDL, maybe you'll also get a much bigger result. The difference between my and your method, that I use anyway more opcodes in the measure loop, which can trigger this more easily.

Ah, sorry for my bad expressing abilities, what I want to say, that maybe this opcode really takes 8 cycles, but after that there is some magic (cache flushing/whatever?) so the next opcode after that will take much longer to be executed finally. Thus my idea if you can measure the execution time of two of this opcodes at once, if I am right, it won't be 8 * 2 = 16 but a much larger value.

[lgblgblgb]

Ok, RTI was my fault, bad test :(

[lgblgblgb]

Other oddity: it seems, cycles spent by multiple opcodes are not exactly of the sum of the cycles of the opcodes one by one ... Just noticed with the "calibration loop" (which measures the cycles needed for the "book-keeping" of the test ie with empty "test payload") is 22 cycles on MEGA65 but 21 cycles on Xemu (with fixes from this project, not committed yet), even though the sum of the cycles should be really 21 according to the opcode timings measured on MEGA65 ... Maybe this affects the difference between the 7 vs 8 cases as well (the SP based ones are similar just way much more radical, probably the mentioned cache/etc magic all over the place in the VHDL when this addressing mode is used?). What I mean here: maybe there is same state which affects opcode timing which is also dependent on the previous opcode executed, so a timing of an opcode cannot be measured cleanly with isolation as there are some effect caused by previous opcode(s) as well, even if it's not always there, but sometimes ...