English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 01 December 2017, 10:53   #1
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
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
Of course the result isn't written and we get v=1.
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)...
meynaf is offline  
Old 01 December 2017, 11:35   #2
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 51
Posts: 3,283
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.
ross is offline  
Old 02 December 2017, 00:11   #3
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,919
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).
phx is offline  
Old 02 December 2017, 11:30   #4
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
Quote:
Originally Posted by phx View Post
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).
$20000000/3 being $0aaaaaaa, how do you get that result of $2000800a ?
meynaf is offline  
Old 02 December 2017, 12:08   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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).
Toni Wilen is online now  
Old 02 December 2017, 12:43   #6
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
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
meynaf is offline  
Old 02 December 2017, 17:50   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
Ok, it seems I need to do real 020/030/040/060 tests.
Toni Wilen is online now  
Old 02 December 2017, 18:25   #8
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 48
Posts: 4,315
As the divide algorithm changed, it seems likely that undefined results also changed.
meynaf is offline  
Old 02 December 2017, 18:33   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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.
Toni Wilen is online now  
Old 02 December 2017, 22:20   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,796
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.
Toni Wilen is online now  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 15:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.11760 seconds with 13 queries