| Re: [hatari-devel] [Bug found] : divul.l |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
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 field:
Specifies 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 field:
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 field:
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 field is 1, this field also specifies 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