[hatari-devel] dsp trace instr

[Laurent Sallafranque]

Le 20/03/2011 12:05, Eero Tamminen a écrit :
> Hi,
>
> On sunnuntai 20 maaliskuu 2011, Laurent Sallafranque wrote:
>> I've reworked the DSP disasm and trace modes.
>> It seems to work well now.
> Looks good to me.
>
>
>> 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.
> What are the differences between DSP trace&  disasm modes and
> when one would use which of them?
>
> ->  This information should be in Hatari manual debugging section,
>     under its own DSP debugging subsection I think.
>

DSP trace is activated when you lauch hatari with option --trace 
dsp_disasm (or when you use this option in the debugger console).

DSP disasm is when you use dd addr in the debugger to disasm a part of 
DSP memory.

With my latest patch, everything works well, also if you use both of 
them at the same time.

>> 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 ?
> How often they're needed compared to the normal disassembling?
>
> Both add a check to speed-critical DSP function, but memory tracing
> would need also switching an often used auxialiary function at run-time.
>

I know I use them a lot when debugging (it's nice to have the 
instruction, and then the register and memory changes).
But it would need to rewrite some more code (maybe in 1.5+ version) ?

>> - 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, ...
> You can set a breakpoint to the condition you like with the ":info" modifier
> and then use the "lock file" info command to give/lock a file containing
> the debugger commands that you want to be run[1] when the breakpoint is hit.
>
> In above case the file should in theory be something like:
> 	trace dsp_disasm
> 	cont 5
> 	trace none
>
> But here's a similar problem as with your DSP disassembling.
> Within the breakpoint, the CPU core flag for entering debugger is set,
> so CPU core returns immediately to debugger instead of continuing for
> 5 instructions.
>
> For now all you can run from breakpoint is the trace command, rest of
> the actions you unfortunately need to do from the debugger prompt yourself.
>
>

OK.