If the div overflow, it will trigger and hardware exception.
Il giorno giovedì 10 novembre 2016 15:01:06 UTC+1, ra...@cockroachlabs.com
ha scritto:
>
> I don't understand. We are truncating the result to 32-bits either way.
> What's the point of computing the entire 64-bits of the result just to
> throw away the high 32?
>
> In your example, A=2^62 and B=13`, `uint32(A / uint64(B))` is (2^62 / 13)
> % 2^32 which I thought is exactly the result of DIV r32.
>
> -Radu
>
> On Thursday, November 10, 2016 at 8:46:02 AM UTC-5, alb.do...@gmail.com
> wrote:
>>
>> When you do a DIV r32 in 64bit mode the result will be saved in
>> EAX but this means that you can only do that if the high word
>> of the dividend is smaller that the divisor.
>>
>> You can't unconditionally replace uint32(A / uint64(B)) with a
>> DIV r32 instruction because if A is big (take 2**62) and B is
>> small (take 13) then the quotient will overflow EAX.
>>
>> A.
>>
>>
>>
>> Il giorno martedì 8 novembre 2016 06:18:02 UTC+1, ra...@cockroachlabs.com
>> ha scritto:
>>>
>>> Sorry to revive an old thread. One thing to note is that dividing a
>>> 64-bit by a 32-bit is much faster than dividing a 64-bit by a 64-bit, at
>>> least on recent Intel platforms. Unfortunately there is no valid way to
>>> express that kind of calculation in Go..
>>>
>>> Is the compiler/optimizer smart enough to figure out it can do that if
>>> you do something like `uint32(a / uint64(b))` where a is `uint64` and b is
>>> `uint32`? (the result of that expression can be computed using the 32-bit
>>> version of DIV)
>>>
>>> On Saturday, January 19, 2013 at 6:10:34 PM UTC-5, Michael Jones wrote:
>>>>
>>>> Integer division is slow.
>>>>
>>>> It is the unloved arithmetic operation in CPU design because of its low
>>>> frequency of occurrence in the instruction stream. It is the one--if you
>>>> remember childhood schooling--that was "not like the others" in its
>>>> mechanism: there was lots of guessing using leading digits, trial
>>>> divisors,
>>>> and so on. This awkwardness exists even in base 2 (though much less) and
>>>> means that any division circuit my have to do at least one "fixup" step.
>>>> (A
>>>> good design does either zero or one fixup, but that one means more work
>>>> and
>>>> plausibly an extra cycle on what is already a long cycle-count activity.)
>>>>
>>>> As one specific example, when adding and subtracting were 1 cycle and
>>>> multiply was 4, a 32-bit integer division required 19 cycles.
>>>>
>>>>
>>>> On Sat, Jan 19, 2013 at 1:25 PM, minux <minu...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 20, 2013 at 5:22 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>>>>
>>>>>> On Sat, Jan 19, 2013 at 10:13 PM, Dominik Honnef <
>>>>>> domi...@fork-bomb.org> wrote:
>>>>>>
>>>>>> Cannot reproduce here (Xeon on dont-know-how-much GHz)
>>>>>>
>>>>>> jnml@fsc-r630:~/src/tmp/20130119$ cat a_test.go
>>>>>> package main
>>>>>>
>>>>>> import (
>>>>>> "testing"
>>>>>> )
>>>>>>
>>>>>> func BenchmarkBase(b *testing.B) {
>>>>>> var x int32
>>>>>> for i := 1; i < b.N; i++ {
>>>>>> }
>>>>>> _ = x
>>>>>> }
>>>>>>
>>>>>> func BenchmarkInt(b *testing.B) {
>>>>>> var x int
>>>>>> for i := 1; i < b.N; i++ {
>>>>>> x /= 42
>>>>>> }
>>>>>> _ = x
>>>>>> }
>>>>>>
>>>>> division by a constant should be turned into multiplication by magic
>>>>> constants
>>>>> by the Go compiler just to avoid the costly divide instruction.
>>>>>
>>>>> you can verify that by 'go tool 6g -S'.
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael T. Jones | Chief Technology Advocate | m...@google.com | +1
>>>> 650-335-5765
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
