Phobos for Review: std.buffer.scopebuffer
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Sat Feb 8 04:24:35 PST 2014
On Saturday, 8 February 2014 at 07:43:06 UTC, Lars T. Kyllingstad
wrote:
> "On many systems alloca() cannot be used inside the list of
> arguments of a function call, because the stack space reserved
> by alloca() would appear on the stack in the middle of the
> space for the function arguments."
>
> So... devil spawn, then?
alloca() is compiler dependent. LLVM has experimental support for
alloca in parameters using a dedicated specification. This is the
downside of depending on backends developed for C. For instance
if the backend emits code that is relative to the end of the
stack rather than the beginning of the stack frame you have to
move down all locals whenever you call alloca():
{
BUFFER64K buffer;
auto dynarr = alloca(smallsize); // triggers a copy of 64KiB and
fucks up all pointers to buffer
}
If you can rely on indexing relative to the beginning of the
stack frame you just have to change the stack pointer. If you
insist on returns of a single dynamic sized temporary being at
the end of the stack upon return (+whatever RET eats) you can
just move your own stack frame, I believe.
Thus not wasting a lot of space of the caller stack frame and
return the length, then the caller can adjust it's own stack
pointer by adding the offset+length. And prepending to that
dynamic array is cheap in simple function bodies, just push
values onto the stack.
But the IR/backend must support it. C-semantics are viral… :-(
More information about the Digitalmars-d
mailing list