01 December 2017, 10:53 | #1 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,358
|
ccr behaviour of div for v=1
Just seen something strange (for me) if a divide ends up in overflow.
This looks like : Code:
move.l #$20000000,d0 divs.w #3,d0 We also get z=0. But, apparently we also always end up with n=1 ! And this, regardless of divu/divs, .w or .l modes, or operand sign. Only check i did so far is winuae in 030 mode. Just wondering if this is the "normal" result (can't check on real hw right now)... |
01 December 2017, 11:35 | #2 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,498
|
From Motorola specs:
"N Set if the quotient is negative. Cleared otherwise. Undefined if overflow or divide by zero occurs." Maybe on real HW N is set and Toni followed it. Also a try in pure 68k mode is due. [EDIT: in overflow case N is a flag to ignore so.. Last edited by ross; 01 December 2017 at 11:43. |
02 December 2017, 00:11 | #3 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,551
|
Test on a real 68SEC000 confirmed N=1, V=1, Z=0.
Not surprising, though. V because of the overflow. And N/Z reflect the result of the overflowed division in D0, which is $2000800a here (negative and non-zero). |
02 December 2017, 11:30 | #4 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,358
|
$20000000/3 being $0aaaaaaa, how do you get that result of $2000800a ?
|
02 December 2017, 12:08 | #5 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
DIV overflow emulation was done before I started with UAE. It seems to be as simple as always setting both N and V. C and Z is always cleared before division operation. I don't remember if these were checked against later CPU models and/or if there are differences between models.
Divide by zero has CPU model specific differences (also undefined in manual). |
02 December 2017, 12:43 | #6 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,358
|
I had to boot up my A1200 just for this but the above code, checked on real 68030, does not set N, only V.
EDIT: $30000/3 does not set Z, even if partial result is zero. However, -1L/1 sets N. Last edited by meynaf; 02 December 2017 at 12:47. Reason: more results |
02 December 2017, 17:50 | #7 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
Ok, it seems I need to do real 020/030/040/060 tests.
|
02 December 2017, 18:25 | #8 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,358
|
As the divide algorithm changed, it seems likely that undefined results also changed.
|
02 December 2017, 18:33 | #9 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
Yeah, flags are probably used by the internal algorithm.
I just quickly tested DIVS with 68020 and 68030, both seems to work identically but undefined bits are not static (like on 68000). For example: $0F000/1 = ZV $0F0F0/1 = NV $1F0F0/1 = V I think this is impossible to reverse without knowing internal algorithm. EDIT: 68040/060 seems to always only set V. Last edited by Toni Wilen; 02 December 2017 at 19:45. |
02 December 2017, 22:20 | #10 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,574
|
After some more testing, I think I found the internal 68020/030 overflow logic.
DIVU: If dividend bit 31 is set (negative), N flag is set. DIVS: If "absolute overflow" abs(dividend >> 16) >= abs(divisor): Neither Z or N is set. This is early exit condition before division. 68000 does the same. If overflow is detected after division: - Z is set if internal result's BYTE part (bits 0 to 7) is zero! - N is set if internal result's BYTE part is negative! Last two conditions are really weird. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
move.w ccr,d0 on 68030 | BlankVector | support.WinUAE | 11 | 05 February 2013 16:46 |
Strange Prefs (non) behaviour. | khph_re | support.WinUAE | 4 | 02 October 2010 14:34 |
Strange A600 behaviour | Gavilan | support.Hardware | 9 | 08 July 2009 19:02 |
Behaviour of COPJMP2? | Anding | Coders. General | 4 | 20 May 2009 18:35 |
68000 Div/divu | dlfrsilver | support.WinUAE | 3 | 01 November 2005 11:31 |
|
|