Re: [hatari-devel] DSPDebug stepping issue

On 29 Dec 2016 22:52, "Eero Tamminen" <oak@xxxxxxxxxxxxxx> wrote:

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@lists.tuxfamily.org
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