Patch for Word64

Simon Marlow simonmar at microsoft.com
Fri Nov 25 08:16:19 EST 2005


On 24 November 2005 11:07, Bulat Ziganshin wrote:

> Hello Matt,
> 
> Thursday, November 24, 2005, 7:52:23 AM, you wrote:
> 
>>>>   int64ToWord64# = unsafeCoerce#
>>>>   word64ToInt64# = unsafeCoerce#
> 
>>     (W32# x#) + (W32# y#)  = W32# (narrow32Word# (x# `plusWord#` y#))
>>     (W64# x#) + (W64# y#)  = W64# (int64ToWord64# (word64ToInt64# x#
>> `plusInt64#` word64ToInt64# y#))
> 
>> The definitions are those used on a 32-bit architecture. So, when it
>> is cheap the plusWord# function is used, but when it is "relatively
>> expensive" then extra conversions are added. Wouldn't it make sense
>> to avoid the conversions in all cases, regardless of whether they
>> are free or not? 
> 
> i'm agree that code simplification you already done is anyway Right
> Thing. so it's better to apply your patch AND add abovementioned
> definitions to help any other operations. about int32ToWord32# and so
> on - they are defined through stg primitives, so anyway defining them
> as unsafeCoerce# must make things a little faster

No, using a primitive for int32ToWord32# is better, because the compiler
knows about primitives and can apply constant-folding.  For example
int32ToWord32# 0# could turn directly into a Word32# value.

Also, unsafeCoerce# must be retained in the Core language, because Core
is typed, even though it compiles to no code.  Its presence in Core
might hinder certain optimisations.

We should really have proper primitives for all these 64-bit operations,
rather than using FFI calls.

Cheers,
	Simon


More information about the Glasgow-haskell-users mailing list