[hatari-devel] dsp trace instr

[Laurent Sallafranque]

Hi,

I've reworked the DSP disasm and trace modes.
It seems to work well now.
I've tested it a lot, but don't hesitate to do some tests too.

I've improved it at the same time :
- no more stack messages (overflow or underflow) in disasm mode on RTI 
and other instructions
- illegal instruction become dc opcode in disasm mode
- dc instructions are displayed with 0 cycles

Now, you can mix trace mode and illegal mode as you want.

I think there's no need to save the loop variable, neither the 
isDsp_in_disasm_mode variable, as they're recomputed each time 
dsp56k_disasm is called.


2 questions :

- Do you think that trace dsp_registers and trace dsp_memory should be 
added to the debugguer or should they stay as DEFINES and recompilation 
in dsp_cpu code ?


- Is there a way to use the debugguer like this ?
        db pc=$'value' and then trace the N next lines of DSP code

DSP debugging sorts so many lines, I's like to be able to just display 
the N next lines after pc = a value, or after a certain register reach a 
value, ...


Regards

Laurent



Le 17/03/2011 21:26, Eero Tamminen a écrit :
> Hi,
>
> On torstai 17 maaliskuu 2011, Laurent Sallafranque wrote:
>> I've uploaded the DSP trace code in hatari.
>> I've tried to optimize it enough to have hatari running normally when
>> DSP isn't in use.
>> DSP Trace mode is still slow when DSP runs (because of number of
>> instructions).
>>
>> It seems to run well, except in one case : if I start hatari with option
>> --trace dsp_disasm and then I enter the dd command, it's broken.
>>
>> dd command works well if hatari is not in trace dsp_disasm mode.
>>
>>
>> I'll try to improve this. Eero, maybe you could have a look too ?
> I think the problem is PC looping check.
>
> Does the attached (untested) patch help?
>
> It prints when looping is detected, resets the related variables
> when disasm init is called + calls the disasm init on disasm loop[1].
> (And makes the returned instruction string const char*.)
>
> [1] I wonder whether some of the stuff done in the loop could be
> moved outside the loop?
>
>
>> Do you think it absolutely need to be fixed before the release ?
>
> 	- Eero
>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110319/ac67d37c/attachment.html>