Re: [hatari-devel] [Bug found] : divul.l

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

> You were dividing zero by 100 (Z flag is set), which results in zero
> and no remainder, so result seems correct.


> move.l        #100,d3
> divul.l    #100000,d3:d4


I thought I wrote :
100/100000 which would have given 0 in d4 (quotient) and 100 in d3 
(remainer)
The 0 in both d3 and d4 seems to be a wrong result to me.


There are 4 different div instructions in the 68030 (1 divu.w and 3 divu.l)
and the same for divs

I think some divu.l are wrong (at least this one)

Laurent


Le 08/11/2012 17:44, Eero Tamminen a écrit :
> Hi,
>
> On torstai 08 marraskuu 2012, Laurent Sallafranque wrote:
> > I think I've found another bug in hatari (new core, but probably old
> > core too).
> >
> > In my test, I've coded the following :
> >
> > move.l        #100,d3
> > divul.l    #100000,d3:d4
> >
> >
> > Hatari disassembled code shows :
> >
> > $05bf88 : 263c 0000 0064                       move.l    #$64,d3
> > $05bf8e : 4c7c 4003 0001 86a0                  divu.l    #$186a0,d4
> Frank Wille also just reported that the external disassembler is
> buggy, he said that it for example doesn't show CMPI instructions
> correctly.   UAE core dissassembler shows them correctly, but
> it's output otherwise less nice.
>
> I've asked him for for more details.  At least the CMPI entry opcode
> mask & value look correct.
>
> There's no entry for divul, just divu.
>
>
> > Hatari Trace mode :
> >   > c 2
> >
> > cpu video_cyc= 27076 452@ 52 : 0005BF88 263c 0000 0064 MOVE.L
> > #$00000064,D3
> > cpu video_cyc= 27082 458@ 52 : 0005BF8E 4c7c 4003 0001
> > 86a0 DIVL.L #$4003,#$000186a0
> Ok, this notices that the args are 32-bit (size field in opcode),
> but gets wrong addressing mode.
>
>
> > Hatari registers before the instruction :
> >
> > CPU=$5bf88, VBL=49175, FrameCycles=37816, HBL=153, LineCycles=74, DSP=$51
> >
> >   > r
> >
> >     D0 00000000   D1 00000000   D2 00000000   D3 00000000
> >     D4 00000000   D5 00000000   D6 00000000   D7 00000000
> >     A0 00000000   A1 00000000   A2 00000000   A3 00000000
> >     A4 0005BF96   A5 0005BF96   A6 00DC16C6   A7 00DC16F8
> > USP  00DC16F8 ISP  00008870 SFC  00000000 DFC  00000000
> > CACR 00000000 VBR  00000000 CAAR 00000000 MSP  00000000
> > T=00 S=0 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
> > FP0: 0 FP1: 0 FP2: 0 FP3: 0
> > FP4: 0 FP5: 0 FP6: 0 FP7: 0
> > N=0 Z=0 I=0 NAN=0
> > 0005BF88 263c 0000 0064           MOVE.L #$00000064,D3
> > Next PC: 0005bf8e
> >
> >   > trace cpu_disasm
> >   > c 3
> >
> > Returning to emulation for 3 CPU instructions...
> > cpu video_cyc= 37816  74@153 : 0005BF88 263c 0000 0064 MOVE.L
> #$00000064,D3
> > cpu video_cyc= 37822  80@153 : 0005BF8E 4c7c 4003 0001
> > 86a0 DIVL.L #$4003,#$000186a0
> I've fixed continue stepping one instruction too little
> after hitting a breakpoint.
>
>
> > CPU=$5bf96, VBL=49175, FrameCycles=37868, HBL=153, LineCycles=126,
> > DSP=$51
> >
> >   > r
> >
> >     D0 00000000   D1 00000000   D2 00000000   D3 00000000
> >     D4 00000000   D5 00000000   D6 00000000   D7 00000000
> >     A0 00000000   A1 00000000   A2 00000000   A3 00000000
> >     A4 0005BF96   A5 0005BF96   A6 00DC16C6   A7 00DC16F8
> > USP  00DC16F8 ISP  00008870 SFC  00000000 DFC  00000000
> > CACR 00000000 VBR  00000000 CAAR 00000000 MSP  00000000
> > T=00 S=0 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=3 STP=0
> > FP0: 0 FP1: 0 FP2: 0 FP3: 0
> > FP4: 0 FP5: 0 FP6: 0 FP7: 0
> > N=0 Z=0 I=0 NAN=0
> > 0005BF96 0000 0000                OR.B #$00,D0
> > Next PC: 0005bf9a
> >
> > After execution, the registers values haven't changed at all.
> You were dividing zero by 100 (Z flag is set), which results in zero
> and no remainder, so result seems correct.
>
>
> > TTDigger disassembler (under hatari) shows the correct code (I've
> > dissassembled the .prg I just compiled before)
> >
> > It seems to me that hatari doesn't emulate well the long word divisions
> > instructions divu.l divul.l ... and divs.l divsl.l ...
> Try with non-zero values for both given registers and
> let's see whether it then looks correct.  :-)
>
>
> > Does someone confirm that ?
>
> 	- Eero