[hatari-devel] DSP optimization?

[Nicolas Pomarède]

Le 15/01/2011 11:57, Eero Tamminen a écrit :
> Hi,
>
> Now that Hatari DSP code doesn't anymore track Aranym, could we change
> the dsp_core to be a static array like CPU core data is?
>
> Accessing the core through a pointer is a small overhead in about everything
> DSP does and we don't gain anything from it as Hatari will never emulate
> more than one DSP at the time (like AFAIK has been the idea with the Aranym
> DSP code).
>
>
> 	- Eero
>

Hello

on contrary to what it may look, it's not obvious that such patch would 
make things faster.

For example on 680xx cpu, "address register indirect with displacement" 
is faster than "absolute long", which means "move.l 12(a5),d0" is faster 
than "move.l $75120,d0".

I don't know for recent cpu (x86, arm or others), but it's also possible 
you get similar results (harder to measure with moderm pipeline/reordering).

It would need to be profiled to see if there's a real different between 
dereferencing a pointer or accessing directly the memory address, but I 
don't think the gain would be noticable on CPU that would benefit from 
it, and it could even be negative on 680x0 cpu or others cpu.

Nicolas


> PS. I once even had a patch for that, but it's of course now out of date
> and I don't remember whether I ever profiled it.
>
> PPS. On quick&  short profiling, Mahabharata DSP bottlenecks seems to
> be dsp_jclr_pp() and dsp56k_execute_instruction() functions, both of them
> executing over 20% of all instructions.
>
> (next ones are interrupt handling, m68k_go(), DSP_Run() with much smaller
> percentages.)
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel