[hatari-devel] DSP optimization?

[Laurent Sallafranque]

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?


I full agree with this.
Aranym code hasn't been updated for ages.
It's so old now, that I think they'll have to take our DSP code now if 
they want to be up to date.

>  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.


Many DSP code will show dsp_jclr_pp() as the main called function.
This code is used to wait datas on the Host Interface port (datas sent 
or received by the 68030).
(It's for synchronizing data transfers between the 2 components).

I don't think I can optimize it much more, the bottleneck comes from the 
number of times a program calls this opcode.

In fact, it depends on how the demo or game code is optimized or not.

Regards,

Laurent


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
>
> 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
>
>