| > Can't we just allocate a Cmm "area"? The address of an area is a | perfectly well-defined Cmm value. What about this idea? Simon | -----Original Message----- | From: Simon Marlow [mailto:marlowsd@gmail.com] | Sent: 08 January 2014 09:26 | To: Simon Peyton Jones; Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: Re: High-level Cmm code and stack allocation | | On 07/01/14 22:53, Simon Peyton Jones wrote: | > | Yes, this is technically wrong but luckily works. I'd very much | > | like to have a better solution, preferably one that doesn't add any | > | extra overhead. | > | > | __decodeFloat_Int is a C function, so it will not touch the Haskell | > | stack. | > | > This all seems terribly fragile to me. At least it ought to be | surrounded with massive comments pointing out how terribly fragile it | is, breaking all the rules that we carefully document elsewhere. | > | > Can't we just allocate a Cmm "area"? The address of an area is a | perfectly well-defined Cmm value. | | It is fragile, yes. We can't use static memory because it needs to be | thread-local. This particular hack has gone through several iterations | over the years: first we had static memory, which broke when we did the | parallel runtime, then we had special storage in the Capability, which | we gave up when GMP was split out into a separate library, because it | didn't seem right to have magic fields in the Capability for one | library. | | I'm looking into whether we can do temporary allocation on the heap for | this instead. | | Cheers, | Simon | | | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Simon Marlow | > | Sent: 07 January 2014 16:05 | > | To: Herbert Valerio Riedel; ghc-devs@haskell.org | > | Subject: Re: High-level Cmm code and stack allocation | > | | > | On 04/01/2014 23:26, Herbert Valerio Riedel wrote: | > | > Hello, | > | > | > | > According to Note [Syntax of .cmm files], | > | > | > | > | There are two ways to write .cmm code: | > | > | | > | > | (1) High-level Cmm code delegates the stack handling to GHC, | and | > | > | never explicitly mentions Sp or registers. | > | > | | > | > | (2) Low-level Cmm manages the stack itself, and must know about | > | > | calling conventions. | > | > | | > | > | Whether you want high-level or low-level Cmm is indicated by the | > | > | presence of an argument list on a procedure. | > | > | > | > However, while working on integer-gmp I've been noticing in | > | > integer-gmp/cbits/gmp-wrappers.cmm that even though all Cmm | > | procedures | > | > have been converted to high-level Cmm, they still reference the | 'Sp' | > | > register, e.g. | > | > | > | > | > | > #define GMP_TAKE1_RET1(name,mp_fun) \ | > | > name (W_ ws1, P_ d1) \ | > | > { \ | > | > W_ mp_tmp1; \ | > | > W_ mp_result1; \ | > | > \ | > | > again: \ | > | > STK_CHK_GEN_N (2 * SIZEOF_MP_INT); \ | > | > MAYBE_GC(again); \ | > | > \ | > | > mp_tmp1 = Sp - 1 * SIZEOF_MP_INT; \ | > | > mp_result1 = Sp - 2 * SIZEOF_MP_INT; \ | > | > ... \ | > | > | > | > | > | > So is this valid high-level Cmm code? What's the proper way to | > | allocate | > | > Stack (and/or Heap) memory from high-level Cmm code? | > | | > | Yes, this is technically wrong but luckily works. I'd very much | > | like to have a better solution, preferably one that doesn't add any | > | extra overhead. | > | | > | The problem here is that we need to allocate a couple of temporary | > | words and take their address; that's an unusual thing to do in Cmm, | > | so it only occurs in a few places (mainly interacting with gmp). | > | Usually if you want some temporary storage you can use local | > | variables or some heap-allocated memory. | > | | > | Cheers, | > | Simon | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs@haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs | >