Re: [hatari-devel] DSPDebug stepping issue

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 12/29/2016 10:55 PM, Mariusz Buras wrote:
> You misunderstand my email. It's not about Hatari built-in debugger. It's
> about Brainstorm's DSPDebug debugger application.

Looking at the DSP56K manual:
---------------
The DSP56000/56001 includes a facility for instruction-by-instruction 
tracing as a program development aid. This trace mode generates a trace 
exception after each instruction executed (see Figure 7-7), which can be 
used by a debugger program to monitor the execution of a program. (With 
members of the DSP56K family other than DSP56000/
56001, use the OnCE trace mode described in 10.5.)

The trace bit in the SR defines the trace mode. In the trace mode, the 
processor will generate a trace exception after it executes each 
instruction. When the processor is servicing the trace exception, it 
expects to encounter a JSR in the trace vector locations,
thereby forming a long interrupt routine. The JSR stacks the SR and 
clears the trace bit to prevent tracing while executing the trace 
exception service routine. This service routine should end with an RTI 
instruction, which restores the SR (with the trace bit set) from
the SS, and causes the next instruction to be traced. The pipeline must 
be flushed to allow each sequential instruction to be traced. The 
tracing facility appends three instruction cycles to the end of each 
instruction traced (see the three NOP instructions shown in
Figure 7-7) to flush the pipeline and allow the next trace interrupt to 
follow the next sequential interrupt.

During tracing, the processor considers the REP instruction and the 
instruction being repeated as a single two-word instruction. That is, 
only after executing the REP instruction and all of the repeats of the 
next instruction will the trace exception be generated.

Fast interrupts can not be traced because they are uninterruptable. Long 
interrupts will not be traced unless the processor enters the trace mode 
in the subroutine because the SR is pushed on the stack and the trace 
bit is cleared. Tracing is resumed upon returning
from a long interrupt because the trace bit is restored when the SR is 
restored. Interrupts are not likely to occur during tracing because only 
an interrupt with a higher IPL can interrupt during a trace operation. 
While executing the program being traced, the trace
interrupt will always be pending and will win the interrupt arbitration. 
During the trace interrupt, the interrupt mask is set to reject 
interrupts below IPL3.
---------------

Is your case one of the exceptions listed above?


	- Eero

> Regards
>
> -----Original Message-----
> From: Eero Tamminen [mailto:oak@xxxxxxxxxxxxxx]
> Sent: Thursday, December 29, 2016 8:36 PM
> To: hatari-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [hatari-devel] DSPDebug stepping issue
>
> Hi,
>
> On 12/29/2016 01:18 AM, Mariusz Buras wrote:
> > I wanted to do some development over holiday season and thought I'll
> > make it easy and use Hatari for DSP development. Immediately I've
> > found an issue with DSP emulation where single stepping in DSPDebug
> > would step two instructions at once instead of one. I remember seeing
> > this few years ago too.
>
> I'm not able to reproduce a situation with Hatari Falcon emulation (= WinUAE
> 030 CPU core + DSP emulation) where "trace dsp_disasm"
> would output more than single instruction with "ds" DSP stepping.
>
> Looking at the Hatari debugger source code, I don't see how that could
> happen either.
>
> Please describe your problem more in detail.
>
>
> 	- Eero