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