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

```Hi,

On torstai 08 marraskuu 2012, Laurent Sallafranque wrote:
> > 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.

First of all, I've never used these instructions,
I just read the 680x0 PDF spec on divu*:
--------
DIVU.W <ea>,Dn      32/16 → 16r – 16q
*DIVU.L <ea>,Dq      32/32 → 32q
*DIVU.L <ea>,Dr:Dq   64/32 → 32r – 32q
*DIVUL.L <ea>,Dr:Dq  32/32 → 32r – 32q

*Applies to MC68020, MC68030, MC68040, CPU32 only.

Description:
Divides the unsigned destination operand by the unsigned source
operand and stores the unsigned result in the destination.
....
The third long form divides a long word by a long word.
The result is a long-word quotient and a long-word remainder.
....
Register Dq ﬁeld:
Speciﬁes a data register for the destination operand.
The low-order 32 bits of the dividend comes from this register,
and the 32-bit quotient is loaded into this register.

Size ﬁeld:
Selects a 32- or 64-bit division operation.
0 — 32-bit dividend is in register Dq.
1 — 64-bit dividend is in Dr – Dq.

Register Dr ﬁeld:
After the division, this register contains the 32-bit remainder.
If Dr and Dq are the same register, only the quotient is returned.
If the size ﬁeld is 1, this ﬁeld also speciﬁes the data register
that contains the high-order 32 bits of the dividend.
---------

I'm reading above so the the register used in division is Dq, not Dr
(unless you do 64-bit division).  Just the results are stored in both.

I.e. in your case D3 register wouldn't be used in calculation,
only in storing part of the result...

I.e. D4/100000 result is 0/0, stored in D4/D3 as D4 was zero.

What do you get if you use instead:
divul.l    #100000,d4:d3

(Or did I misunderstand?)

- Eero

> 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

```

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/