High-level Cmm code and stack allocation

Simon Marlow marlowsd at gmail.com
Tue Jan 7 16:20:10 UTC 2014


On 07/01/2014 16:14, Herbert Valerio Riedel wrote:
> Hello Simon,
>
> On 2014-01-07 at 17:04:52 +0100, Simon Marlow wrote:
>
> [...]
>
>> Yes, this is technically wrong but luckily works.
>
> ...but only as long as the code-generator doesn't try to push something
> on the stack, like e.g. when performing native 'call's which need to
> push the return-location on the stack...?

Right - in principle the code generator is in control of the stack so it 
can move the stack pointer whenever it likes, but in practice we know it 
only does this in certain places, like when making native calls, so 
these naughty functions just avoid doing that.

>> I'd very much like
>> to have a better solution, preferably one that doesn't add any extra
>> overhead.
>
> I see... I've noticed there's a 'push() { ... }' construct that allows
> to push items on the stack; couldn't we have generalized version of
> that, taking a size-argument, declaring that specified amount of
> stack-space is user-allocated/controlled within the '{ ... }' scope?

We could push a stack frame, like we do for an update frame, but the 
problem is that we need a way to take the address of those stack 
locations.  Taking the address of stack locations is also dodgy, because 
stacks move (say, during a native call).  So it would still be unsafe. 
Also pushing a stack frame would incur an extra memory write for the 
info pointer, which is annoying.

Cheers,
Simon


More information about the ghc-devs mailing list