|
Yes, just print it from the dsp ram,
that's the easiest way to get a source code.
I think I should write a dsp code extractor one day (some code
that would extract some DSP from memory in a nearly recompilable
style).
Regards
Laurent
Le 22/11/2015 23:29, Andreas Grabher a écrit :
Laurent and Douglas, you are of course right. This should be
checked on real hardware. I try to find someone to test it for me.
But until then, given the sense for perfection of all NeXT stuff,
i think it is quite unlikely they shipped it with that obvious
bug. There are also obvious issues (black line in the middle), if
the default parameters are used.
I'll report back as soon as is have information from real
hardware.
Laurent, i tried to answer your questions below.
Douglas, your optimizations are interesting. I think NeXT
would have been interested in them, because the main purpose
of the Mandelbrot demo was to demonstrate the performance
advantage of the DSP over the CPU for certain tasks ;-)
I'll have a look if i can isolate the complete DSP
application. It seems to be embedded into the binary. Maybe
i'll just print if from the DSP RAM ...
Hi Andreas,
First, are you sure the resulting bad pixels don't
appear on the real computer too ?
(just to be sure).
When I have a closer look at the trace, I can read :
; Previous loop
p:0099 0af0a5 0000a1 (06 cyc) jec
p:$00a1
; New loop that seems to bug
p:00a1 2000d8 (02 cyc) mpy
+y0,x0,b
Reg: b $00:4a0b9a:44a2c4 ->
$00:2355a0:579062
Reg: sr $8040 -> $8050
p:00a2 20003a (02 cyc) asl
b
Reg: b $00:2355a0:579062 ->
$00:46ab40:af20c4
Reg: sr $8050 -> $8040
; Is the next one correct ? (we have b = $00:8...
) ?
I think this is all correct. It gets back to 00:7... later
just before the jec.
p:00a3 20003a (02 cyc) asl
b
Reg: b $00:46ab40:af20c4 ->
$00:8d5681:5e4188
Reg: sr $8040 -> $8060
; What worth Y1 value just below ? (I haven't found
it in the trace)
; The problem may be here
y1 is 0x2c28f8, it gets set up at the beginning and does
not get changed during the calculation.
p:00a4 200078 (02 cyc) add
y1,b
Reg: b $00:8d5681:5e4188 ->
$00:ae4c44:5e4188
; Just below, we've got the "overflow" (7fffff)
(into y0)
; The problem seem to be that the program copy
$00:ae4c44:5e4188 into y0 and set it to $7fffff
I think that overflow is normal behavior. But i'm not sure
about it.
p:00a5 21e696 (02 cyc) mac -y0,y0,a
b,y0
Reg: y0 $4e71df -> $7fffff
Reg: a $00:19f86d:2f6242 ->
$ff:e9e540:1a21c0
Reg: sr $8060 -> $8058
p:00a6 200032 (02 cyc) asl
a
Reg: a $ff:e9e540:1a21c0 ->
$ff:d3ca80:344380
Reg: sr $8058 -> $8059
p:00a7 200060 (02 cyc) add
x1,a
Reg: a $ff:d3ca80:344380 ->
$ff:fff376:344380
Reg: sr $8059 -> $8058
p:0096 21c498 (02 cyc) mpy +y0,y0,b
a,x0
Reg: x0 $39a7ef -> $fff376
Reg: b $00:ae4c44:5e4188 ->
$00:7ffffe:000002
Reg: sr $8058 -> $8040
p:0097 200080 (02 cyc) mpy
+x0,x0,a
Reg: a $ff:fff376:344380 ->
$00:000001:3a74c8
Reg: sr $8040 -> $8050
p:0098 200018 (02 cyc) add
a,b
Reg: b $00:7ffffe:000002 ->
$00:7fffff:3a74ca <-- Here KO
?
The problem seems to that unlike with the "good" pixels, a
is too small to get to 00:8...
Reg: sr $8050 ->
$8040
p:0099 0af0a5 0000a1 (06 cyc) jec
p:$00a1
Laurent
Le 22/11/2015 10:24, Andreas Grabher a écrit :
Update:
Looking at the values of b at time of final jec
it seems that it might also be some kind of
rounding issue:
00:800d9f:248aca <--- 3 pixels before
00:80064e:53e34a
00:8001b2:34bbf4
00:7fffff:3a74ca <--- bad pixel
00:80016c:07e922
00:800631:562b04
00:800e89:ff27ca <--- 3 pixels after
Anfang der weitergeleiteten Nachricht:
Betreff:
[hatari-devel]
DSP Mandelbrot bug
Datum:
22.
November 2015 09:53:17 MEZ
Hello Hatari Community,
i am experiencing a hard to find DSP bug
here with Previous. Luckily it can be made
"visible" using NeXTstep's included
Mandelbrot demo. It might also be
responsible for some distorted audio in
other applications.
I appended a screenshot of the mandelbrot
application where the effect of the bug is
clearly visible. I pointed to one failing
pixel. I also appended some debugging output
containing the calculation of the failing
pixel and one pixel before and one after the
failing one. The last file i appended
contains an overview about the variables
during calculation to get a better overview.
Short overview on the calculation:
Every pixel is calculated separately. The
visible pixel color is derived from the
remaining loop count of some calculation.
The higher the remaining count, the lower is
the output value of the function. The loop
exits using a jec instruction (check
extension bit, exit if false).
For the "good" pixels it exits after the
second run, because the upper 9 bits of b
are no longer all 0. For the "bad" pixel it
does not exit, because these bits are still
all 0. The most suspect part of the
calculation seems to be mpy +x0,x0,a at
p:0097. The value of a after the third call
of that instruction seems to not fit into
the pattern.
Can someone with more DSP experience see the
bug? It might or might not be in dsp_mul56.
Any help is greatly appreciated!
Andreas
|