Re: [hatari-devel] DSP Mandelbrot bug

On 22 November 2015 at 18:59, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

A quick look at the disasm in the log suggests the code was written that way with a compromise (or bug) embedded in it.

It basically eliminates a bound test (compare), favouring an extension flag (jec) to escape the loop, and the rest of the arithmetic seems left-justified by an extra bit, to encourage this overflow. This aside it looks like a literal translation of a Mandelbrot routine. Was probably done as a weird optimization (Although it lacks some other possible optimizations which seem more obvious).

Best check it on a real NeXT - but chances are Hatari is ok here (?)

D

On 22 November 2015 at 13:37, Andreas Grabher <andreas.grabher@xxxxxxxxxxxx> wrote:
Sorry, maybe i should have made some comments on this. The lines represent the three pixels (good, bad, good) and the "rows" represent the values for each iteration.

So the middle one is for the bad pixel:
first iteration: 00:0f3c36:3b98c8, second iteration: 00:19f86d:2f6242, third iteration: 00:000001:3a74c8

Laurent, i'll have look at your message later today.

Am 22.11.2015 um 11:30 schrieb Miro Kropáček <miro.kropacek@xxxxxxxxx>:

I'm sorry if I'm too stupid but why there are nine numbers?

p:0097: mpy +x0,x0,a:
a: 00:0f03e3:fb98c8, 00:194a4e:263282, 00:0001b4:34bbf2
a: 00:0f3c36:3b98c8, 00:19f86d:2f6242, 00:000001:3a74c8
a: 00:0f74f0:a67382, 00:1aa999:8e44c2, 00:00016e:07e920

I'd expect to have here three results (for each iteration), esp. if the result of the multiplication seems to be the middle one.

On Sun, Nov 22, 2015 at 10:24 AM, Andreas Grabher <andreas.grabher@xxxxxxxxxxxx> wrote:
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:

Von: Andreas Grabher <andreas.grabher@xxxxxxxxxxxx>
Betreff: [hatari-devel] DSP Mandelbrot bug
Datum: 22. November 2015 09:53:17 MEZ
An: hatari-devel@xxxxxxxxxxxxxxxxxxx
Antwort an: hatari-devel@xxxxxxxxxxxxxxxxxxx

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

--
MiKRO / Mystic Bytes
http://mikro.atari.org