On Fri, 24 Dec 2010 11:36:23 +0100, Eugene Kirpichov <[email protected]> wrote:

Hello,

2010/12/24 Henning Thielemann <[email protected]>:

:
:
Maybe you succeed to find out machine endianess at
compile time. Then you could use native memory access if the user requested
endianess is the one of the machine. If you achieve this, you could
implement peek and poke of Float and Double by just reversing the byte order into an 'alloca'd memory area and peek from and poke into this one with a
native peek or poke, respectively. That is you would not need any
unsafeCoerce anymore.
I don't think I'd like to allocate memory in these functions - I
expect them to have very predictable and very high performance.
I'm using unsafeCoerce because it allows me to treat all these types
in the same fashion (which is good for correctness and readability),
and unsafeCoerce's semantics is identical to what is expected of this
code - interpret a memory area as a value of a different type.

You're right however that some support could be added for host
endianness - once I think something up, I'll do it; maybe this could
be done with a couple unsafePerformIOs and runtime tests :)


You could use ADNS.Endian.endian from package hsdns in your Setup.hs to define endianness at compile time.

Regards,
Henk-Jan van Tuyl


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--

_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to