>> On x86, the case that msword >= divsor causes a divide exception
>> (divide ba generalization of divide by zero), so it's tempting
>> to do the same sort of "assume no trap and fix up in the handler"
>> trick as .
> That would be horrible. One of the reasonably common cases of do_div()
> is for
On Thu, Aug 13, 2015 at 11:18 AM, George Spelvin wrote:
>
> On x86, the case that msword >= divsor causes a divide exception
> (divide ba generalization of divide by zero), so it's tempting
> to do the same sort of "assume no trap and fix up in the handler"
> trick as .
That would be horrible. On
> I'm not convinced that "64/32->32" is all that generic, though. If
> the dividend in 64-bit, there's no fundamental type-based guarantee
> that things will fit.
I agree that it's impossible to decide based on the types, but having
that knowledge is extremely common. Which is why it would be ni
On Wed, Aug 12, 2015 at 11:11 PM, George Spelvin wrote:
>
> Agreed. But some x86 code I'm working on now, I have a *lot* of
> asm("divl") calls because even do_div isn't great for 64/32->32 division.
Yeah.
I'm not convinced that "64/32->32" is all that generic, though. If
the dividend in 64-bi
Linus wrote:
> Ugh. gcc still does a pretty horrible job at it. While gcc knows that
> a widening 32x32->64 multiplication can be simplified, it doesn't do
> the same thing for a 64/32->64 division, and always calls __udivdi3
> for it.
Agreed. But some x86 code I'm working on now, I have a *lot*
5 matches
Mail list logo
