Re: [Haskell-cafe] FFI and modifying haskell memory
Am Montag, 24. Oktober 2005 17:20 schrieb Joel Reymont: Is with better than allocaBytes? with is just a utility function around alloca and poke, where alloca is another utility function around allocaBytes. Here the code from the repository: with val f = alloca $ \ptr - do poke ptr val res - f ptr return res (Hmmm, why not simplify the last two lines to just f ptr?) GHC does some tricky things you probably don't want to know about :-) to do something better for alloca than an exception-protected malloc/free pair. In a nutshell: with is not better than allocaBytes, it is something different. with can be used to pass a Storable Haskell value in a temporary memory buffer to a function, while allocaBytes only does plain temporary memory allocation. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI and modifying haskell memory
So both with and allocaBytes allocate bytes on the stack then, correct? On Oct 29, 2005, at 1:13 PM, Sven Panne wrote: In a nutshell: with is not better than allocaBytes, it is something different. with can be used to pass a Storable Haskell value in a temporary memory buffer to a function, while allocaBytes only does plain temporary memory allocation. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI and modifying haskell memory
Am Samstag, 29. Oktober 2005 14:27 schrieb Joel Reymont: So both with and allocaBytes allocate bytes on the stack then, correct? It depends on what you mean by stack. :-) From a conceptual point of view, both pass a pointer to a temporary memory region to a given action *which is only valid during the execution of the action*, so it would be incorrect to if the pointer somehow escapes the action. How this temporary memory is actually allocated depends on the implementation: Hugs and NHC use malloc/free, ensuring that free is even called in case of an exception, so that there will be no space leaks. GHC does something more efficient by allocating the memory from the normal Haskell runtime heap, but ensuring that the memory is never moved by garbage collection. This is called pinned memory sometimes, see e.g. Java's JNI. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI and modifying haskell memory
Is with better than allocaBytes? On Oct 22, 2005, at 12:42 AM, John Meacham wrote: because haskell values don't have the same representation as C values. haskell values are pointers to updatable thunks. in any case 'with' just allocates 4 bytes on the stack (the same as a auto C declaration) so is quite speedy compared to what it would take to make a haskell value look like a C one. not to mention haskell values can't be modified. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI and modifying haskell memory
Am Samstag, 22. Oktober 2005 01:42 schrieb John Meacham: On Fri, Oct 21, 2005 at 03:19:36PM +0100, Joel Reymont wrote: Is there a particular reason why StablePtr cannot provide a fixed memory address? Then 4 bytes of memory won't need to be allocated so that C could write to them and C could just modify the Haskell variable. because haskell values don't have the same representation as C values. haskell values are pointers to updatable thunks. in any case 'with' just allocates 4 bytes on the stack (the same as a auto C declaration) so is quite speedy compared to what it would take to make a haskell value look like a C one. not to mention haskell values can't be modified. 2 tiny remarks: * In Simon's example the first parameter to 'with' (the initial buffer size) was missing, but I guess you've figured this out already. In general: If the pointer you're passing to C has in semantics, 'with' (or one of its variations) is your friend. For in/out semantics, use 'with' + 'peek', and for out semantics use 'alloca' + 'peek'. * As already mentioned, StablePtr can even refer to something which has no direct C counterpart, like Haskell functions. Needing them in the C world seems strange at first, because there is nothing thrilling you can do with them but pass them back to Haskell. But there are actually some good uses for that, like interfacing to callback-based C APIs where some additional bookkeeping is needed. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] FFI and modifying haskell memory
Folks, I stumbled upon this when binding the Zlib library and want to make sure I'm doing this right. foreign import ccall unsafe uncompress uncompress_ :: Ptr Word8 - Ptr CULong - Ptr Word8 - CULong - IO CInt You give this function the address of your size as second argument and it updates size for you. basic uncompress(char* buf, unsigned long *size, ...) for you. Is it correct that I need to allocate a chunk of 4 bytes to be passed into C and updated there and then need to peek my value from that chunk of memory? I thought StablePtr would give me the address of a Haskell value but it gives me an offset into some table instead. Thanks, Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI and modifying haskell memory
Is there a particular reason why StablePtr cannot provide a fixed memory address? Then 4 bytes of memory won't need to be allocated so that C could write to them and C could just modify the Haskell variable. On Oct 21, 2005, at 3:17 PM, Simon Marlow wrote: yes, something like with $ \pculong - r - uncompress_ buf pculong ... size - peek pculong I thought StablePtr would give me the address of a Haskell value but it gives me an offset into some table instead. That's right, the reason being that Haskell values move around when GC happens. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI and modifying haskell memory
On Fri, Oct 21, 2005 at 03:19:36PM +0100, Joel Reymont wrote: Is there a particular reason why StablePtr cannot provide a fixed memory address? Then 4 bytes of memory won't need to be allocated so that C could write to them and C could just modify the Haskell variable. because haskell values don't have the same representation as C values. haskell values are pointers to updatable thunks. in any case 'with' just allocates 4 bytes on the stack (the same as a auto C declaration) so is quite speedy compared to what it would take to make a haskell value look like a C one. not to mention haskell values can't be modified. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
