[Feature Request] Cycle Exact for other Cpu

[Zilog]

Hy Tony,
it possibile emulate cycle exact for 68030,68040 and 68060.

Thanks a lot.
By Zilog.

[Toni Wilen]

68020 isn't very accurate either.

It is only possible if someone finds out how CPU internal instruction sequencer work. exactly. (68040+ isn't really worth the trouble, programs that need 68040+ usually is well behaving enough to not care about exact accuracy)

[Zilog]

Originally Posted by Toni Wilen

68020 isn't very accurate either.

It is only possible if someone finds out how CPU internal instruction sequencer work. exactly. (68040+ isn't really worth the trouble, programs that need 68040+ usually is well behaving enough to not care about exact accuracy)

Ok. Thanks Tony.

[demolition]

I guess even 68020 is not too important to have 100% cycle accurate since most 020 code is not timing-critical like 68000 demos and games which could be very dependent on raster timing etc. This was not really the case with 020 since there was no real 'standard' 020-based Amiga except for the 1200, but by that time several other 020-solutions already existed in Amiga-land so people knew that it was not wise to code towards a specific device. Also, many people put accelerators in their 1200s, so doing something timing-critical would not sell well.
The only 020-based platform that did not 'suffer' from accelerators being common etc. would maybe be the CD32, but then I think that most games for that one would also have been released for A1200/A4000.

[meynaf]

Yet it's a pain when optimising code for 020-030 because it can't be tested on anything but real hw...

[demolition]

Even on real HW you still have several versions to choose from, i.e. multiple clock frequencies which will interfere with the timing since the chip mem is still running as slow as ever.

But I can see that it would be nice to be able to measure the timing reasonably well so you validate code optimizations in loops etc. But just how inaccurate is the 020 emulation timing?

[meynaf]

Originally Posted by demolition

Even on real HW you still have several versions to choose from, i.e. multiple clock frequencies which will interfere with the timing since the chip mem is still running as slow as ever.

Only a handful routines that need optimisation actually touch chipmem and in many cases the exact timing is "hidden" by write pipelining.

Originally Posted by demolition

But I can see that it would be nice to be able to measure the timing reasonably well so you validate code optimizations in loops etc. But just how inaccurate is the 020 emulation timing?

I don't know if it has been changed since, but 3.1.0 on which i tested isn't even remotely exact. I found something taking 4 clocks isn't twice the time as something taking 2, etc. In fact, nothing appeared to be right at all

[demolition]

Originally Posted by meynaf

Only a handful routines that need optimisation actually touch chipmem and in many cases the exact timing is "hidden" by write pipelining.

I guess if it is running on a machine without fastmem like a plain A1200, then it will touch chipmem quite a bit.

[Toni Wilen]

Not again?

68020 cycle exact is very important but as I said, unless someone tells me how internal cycle sequencer work (or gets access to internal cycle sequencer bus request signal!). I have totally lost interest with 68020 cycle accuracy unless someone finds something that is actually helpful.

Average timing or those tables in 68020/030 manual are practically useless for accurate emulation purposes.

Then there is DIV and MUL that are variable cycle count. Totally unknown cycle usage. 68000 documented average values were also useless. Fortunately someone bothered to examine 68000 patent microcode listings to decode the actual logic.

[demolition]

I guess someone could etch the top off an 68020 and implement all the gates 100% accurately in VHDL. Then you'd have something to work with. :-)

[meynaf]

Originally Posted by demolition

I guess if it is running on a machine without fastmem like a plain A1200, then it will touch chipmem quite a bit.

Yes but this is not the case i would care about
And anyway this doesn't change the timing when the code is in icache.

Originally Posted by Toni Wilen

Not again?

Yes, again

Originally Posted by Toni Wilen

68020 cycle exact is very important but as I said, unless someone tells me how internal cycle sequencer work (or gets access to internal cycle sequencer bus request signal!). I have totally lost interest with 68020 cycle accuracy unless someone finds something that is actually helpful.

68000 is very memory bound so that bus cycles are important. 68020/68030 is not.

Originally Posted by Toni Wilen

Average timing or those tables in 68020/030 manual are practically useless for accurate emulation purposes.

There is something between 100% accurate and 100% wrong, I think.
If we have two instructions with same timing on real hw then the emulator should at least use the same timing for them - and it doesn't appear to be the case today.
Some are 2,4,6, or 8 clocks if in icache and this does not depend on anything external so timing ratios should at least be respected in the general case.

Originally Posted by Toni Wilen

Then there is DIV and MUL that are variable cycle count. Totally unknown cycle usage. 68000 documented average values were also useless. Fortunately someone bothered to examine 68000 patent microcode listings to decode the actual logic.

Not totally unknown, no. Register MUL timing appears to be 26 clocks if multiplier is zero, else 28.
DIV is too rare for exact timing to be that important ; keeping what we have now is enough. A good estimate would be to take the best timing and add 2 clocks.

So once again, even if cycle exact can not be reached, something close enough can still be done.
If i get a timing that's 2% different than real hw, it's quite acceptable. NOT if i get 25% difference (or something so chaotic i cannot even get a clock rate estimate). Do you agree ?

[Toni Wilen]

It does not work that way because if instruction accesses chip ram (which is main reason for 68020 ce, running unexpanded A1200 demos accurately), length of instruction can change greatly and trying to fit it with cached instructions correctly is the problem. It requires more accurate cycle sequencer emulation, even switching data <> prefetch access order can change speed of execution in chip ram bandwidth starved situation much more than 2x! And this is the problem with unexpanded A1200. (AGA chipset/chip ram CPU access still takes 2 color clocks = same as 68000 memory cycle! Fortunately it is at least 32-bit wide)

Your use case is something totally different, "fixing" that would not help my goal and most likely would only make it worse.

It needs proper improvement that works with both cases.

[meynaf]

Originally Posted by Toni Wilen

Your use case is something totally different, "fixing" that would not help my goal and most likely would only make it worse.

It needs proper improvement that works with both cases.

So what is done currently that would break with more accurate timings for full-in-icache loops ?

[honx]

can a moderator please rename "fectures" into "features" in both thread titles?
this is driving me up the wall, totally makes me nuts! maybe some kind of ocd?...