On Jul 20, 2008, at 8:11 PM, Richard A. O'Keefe wrote:
I read this as
"Is there any way to take a 32-bit float in a register and end up
with a 32-bit int
in a register, without going through memory, in GHC?
How about the other way around?
How about 64-bit floats and integers?"
It is rather hard to do portably in GHC what some hardware does not
do.
The reason to provide this as a primitive is so that code like Complex
magnitude doesn't have to go through a completely opaque-to-the-
compiler interface in order to extract bits from the underlying IEEE
float representation. Sure, code generation can't assign it to a
register, but it could be kept on the stack. Once we're peeking and
poking through a Ptr (the trick that was suggested the last time this
came up, too, if I remember rightly) we're sunk---GHC doesn't reason
well at all about this stuff, and we need to allocate a Ptr to peek
and poke. If instead we use a foreign call, again, it's completely
compiler-opaque.
A long time ago hardware architects decided that separating the
integer and
floating point register files was a Good Thing.
The machine I know best is SPARC, where there are no instructions to
move
data directly between integer registers and floating point registers.
Ironically, this is no longer true on Niagara-class (T1 and T2) SPARC
machines. So nowadays this may be the only architecture that *does*
provide this ability. But again, the really important thing is that
the compiler can see that bits is bits and that the conversion
involves no magic and no extra storage beyond a spill location on the
stack.
... [stuff about SIMD snipped]...
All things considered, I wouldn't worry about it too much: the
memory in
question should be at the top of the stack, so should be in L1
cache, so should
be pretty fast to access, and other things may be more significant.
But only if GHC can treat them transparently---which at the moment it
evidently can't!
All it'd take is a primitive from Float# -> Int32# and another from
Double# -> Int64#...
-Jan-Willem Maessen
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
