Re: [hatari-devel] DSP performance

[ Thread Index | Date Index | More 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

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.


Mail converted by MHonArc 2.6.19+