|Re: [hatari-devel] DSP performance|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 28/06/2015 23:47, Laurent Sallafranque a écrit :
Until now, I've always thought that the first fight for Falcon emulation
was the accuracy of the CPU cycles, as the cpu is THE clock for all the
When I did the static cycles table in the previous version of hatari
(until 1.8), I did recompute the whole table for 16 bits memory acces
and for .w or .l instructions (cycles are different due to the cycle
Maybe the current 68030 cycles are for a 32 bit computer (as the amiga
68020 is) and the cycles are not recomputed for a 16 bits BUS. As the
cpu core is issued from winUAE, it may be something like that.
Maybe there's something else to search ;)
I know my static table was not perfect at all, but it seemed to give a
not so far timing accuracy from a real falcon.
I spent more than 1 month recomputing the figures according to Mikro's
documentation about 68030 cycles in the Falcon.
I don't know where the cycles are computed in the new engine (I should
take the time to have a closer look at this).
in WinUAE CPU (as in old UAE CPU), cycles are computed not with a table
but with some basic sets of "rules" that combine the time needed to
prefetch, to access memory, to do bit operations, arithmetic and so on,
taking into account the operand size.
On the average, it's possible the table gave better results, or better
results for the instructions that are most commonly used on Falcon when
cycle accuracy is needed.
But it didn't take instr/data cache into account by using the real logic
as in a 68030 (it was some worst/best case values)
And in the end, it was too difficult to merge new WinUAE cpu with this
table, there're too much differences in both approaches.
Also, I have the feeling the table was based on 68020, not 68030 ? For
example, NOP took 2 cycles in cache and 4 cycles with no cache, but
68030 doc says it's always 2 cycles (same for EXG dx,dy, timings are
different between cache and no cache, but it should not be the case).
All in all, I have no "fit all" solution. Keeping an old version of
WinUAE CPU core was not good, as many 68000 CE behaviour are handled
much more cleanly/accurately in latest WinUAE ; and this also fixed
several games/demos for Falcon that didn't work before.
By comparing real Falcon cycles result with latest Hatari, we will be
able to spot some differences and this could give hint on how some
instructions should work internally to reach the correct number of
cycles, but until then, we will have a mix of improvements/regressions.