|Re: [hatari-devel] DSPDebug stepping issue|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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?
From: Eero Tamminen [mailto:oak@xxxxxxxxxxxxxx]
Sent: Thursday, December 29, 2016 8:36 PM
Subject: Re: [hatari-devel] DSPDebug stepping issue
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
Please describe your problem more in detail.