High-level Cmm code and stack allocation

Simon Marlow marlowsd at gmail.com
Tue Jan 7 16:04:52 UTC 2014


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


More information about the ghc-devs mailing list