To resume :
when TRACING code, my values are OK [xx cycles]
when PROFILING code, Eero's values are OK
when DISASSEMBLING code, you can't rely on the cycles values.
Ahaa, ok - I understand now :-) makes sense.
PS: So, my +1 per extra memory access should be good. Yeahhh ! ;)
So I may have been wrong about this one in my last message...
In fact I wrote a test for this long ago (but forgot about it until you asked today! :-)
For the simple case 2-cycle parallel move instruction, on a 40MHz DSP...
DSP ( X:Int Y:Int P:Int ) -> 20.000 Mips (~125%) = 2 osc cycles
DSP ( X:Ext Y:Ext P:Int ) -> 10.000 Mips (~125%) = 4 osc cycles
DSP ( X:Ext Y:Ext P:Ext ) -> 6.666 Mips (~125%) = 6 osc cycles
So it seems that the penalty is +2 osc for each external memory conflict, not +1....
This test runs the same code with addr registers pointing at different locations (except for P: which is a copy of the code at a different ORG:)
I have now run the same test in Hatari (32MHz DSP)...
DSP ( X:Int Y:Int P:Int ) -> 16.045 Mips (~100%) = 2 osc cycles
DSP ( X:Ext Y:Ext P:Int ) -> 6.416 Mips (~80%) = 5 osc cycles (???)
DSP ( X:Ext Y:Ext P:Ext ) -> 5.347 Mips (~100%) = 6 osc cycles
...and the results are a bit strange for the 2nd case. However the other two cases look correct? Generally this isn't what I expected to see for a +1 penalty for each conflict. I expected to see 2,3,4 cycles instead.
Laurent - let me know if you need this test program and code, or if you need me to change the test in any way. Perhaps you have some ideas as to what's happening here.
D.