| Re: [hatari-devel] DSP performance |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 02/07/2015 11:29, Adam Klobukowski a écrit :
the problem we actually have with falcon in Hatari is that we *don't
know in advance* the instructions' cycles (at least not all of them
are correct)
Not knowing the perfect cycle count for an instruction is not the same
as not knowing it in advance.
Then I don't understand what you mean. Of course, we know the cycle
count in advance (or just after, but that doesn't matter), it's just
that in many cases it's not correct. And when you don't have perfect
cycles count for every instruction, we see the result : dsp and cpu gets
out of sync and report speed difference when compared to real HW. So,
what do you propose, I don't see your point ?
Not really. CPU already has a context, and it would just need to
remember what instruction is executing, and actually 'execute' it when
it finishes. It might be more complex if real bus access times would be
emulated.
What do you mean by CPU already has a context ? Where ? Cpu emulation
has no context of where it is *inside* an instruction (in which part of
the micro code) to do a return and to proceed at the same point on the
next call, doing this by steps of 2 cycles until the whole instruction
is complete.
I'm afraid you're over-underestimating the complexity of emulating
68000/20/30 with bus access *and* keeping a decent emulation speed.
Once again : the root of all differences for now in Falcon mode is that
some instructions don't have their correct instruction cycle for 68030.
If it was the case, then it would work, no need to split instructions in
piece of 2 cycles (the fact that STF/STE emulation works without doing
this shows that it's a correct solution).
It's more efficient to run each instruction as a whole, but to
update all other component each time the microcode of the
instruction do a bus access for example (this is how WinUAE works in
CE mode for Amiga : during the emulation of 1 complete instruction,
it will update copper, blitter, fdc, ...)
This it not limited to knowing 680x0 exact cycles, but the fact that
other chips steal bus accesses too, especially Videl. I've briefly
checked Videl code, and I don't see any cycles counted there. Without
it, DSP/CPU sync won't ever be good enough, especially for demos that
set up weird video modes.
This is known limitation and was already discussed before.
Nicolas