ccr behaviour of div for v=1

[meynaf]

Just seen something strange (for me) if a divide ends up in overflow.
This looks like :

 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)...

[ross]

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..

[phx]

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).

[meynaf]

Originally Posted by phx

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 ?

[Toni Wilen]

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).

[meynaf]

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.

[Toni Wilen]

Ok, it seems I need to do real 020/030/040/060 tests.

[meynaf]

As the divide algorithm changed, it seems likely that undefined results also changed.

[Toni Wilen]

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.

[Toni Wilen]

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.