Re: [hatari-devel] DSP patch suggestion

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]




Am 10.12.2023 um 13:47 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:



Am 06.12.2023 um 19:27 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:


Am 04.12.2023 um 19:32 schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:

Am 03.12.2023 um 22:50 schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
Thanks for splitting your patches and sharing them (I just had to remove the reference to "dsp_core.dma_address_counter=0", Hatari has no dma_address_counter member)
I applied to Hatari, for regular Falcon users (Laurent :) ), please check you don't see any regression
Nicolas
Great! Sorry for the trouble with dma_address_counter. It is part of the DMA interface and i forgot to remove it for Hatari.

Regards,
Andreas
Just out of curiosity: Did someone test the new code? Are there any noticable improvements or (hopefully not) regressions?

While modifying the DSP code for Previous I noted some structural issues with the code. It seems the DSP code contains quite some modifications specific to Atari. It mostly affects reading and writing external RAM. Wouldn’t it be better to do this outside of dsp_cpu.c? For example external RAM access code could be moved to dsp.c and called via function pointer as it is done with dsp_host_interrupt() (e.g. uint32_t dsp_ramext_read(int space, uint16_t address) and void dsp_ramext_write(int space, uint16_t address, uint32_t value)). 

What do you think?

btw. full DSP ROM simulation is now online for Previous (can be configured to use the old method):
https://sourceforge..net/p/previous/code/1362/

May I suggest another patch?

The appended patch removes some constants that are kind of duplicate. It also makes readout of access_to_ext_memory a bit more safe (in case someone changes to values of the constants).
Furthermore it cleans access_to_ext_memory handling a bit. This might be slightly slower (1 << variable instead of 1 <<  constant) but saves quite some code. On the other hand it replaces "address += DSP_RAMSIZE>>1" with "address |= DSP_RAMSIZE>>1" which might be a bit faster unless the compiler already detected the optimisation potential (and makes more sense when thinking about what real hardware does).

You might want to apply the whole patch or parts of it.

Regards,
Andreas
 

Attachment: hatari_dsp_cleanup.diff
Description: Binary data



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/