the question of alloca came up.
It has come up before. Charles can say what I'm about to say more
correctly, but:
IIUC, the few times this has come up before, the point has been made that
fixed stack frame size is pretty key to how the Plan 9 toolchain works. For
one thing, it's why we don't really need a frame pointer, because, given a
fixed size stack frame, you can use the SP to act as a frame pointer. It is
pretty clear if you look at assembly, then the binary, to see what is going
on.
Why would you want to look at assembly AND binary? Plan 9 assembly is
unlike old-school assembly: don't assume, when looking at a plan 9 .s,,
that you're looking at what the binary will look like. Just one example,
relative jumps are in units of instructions, not bytes; which is pretty
wonderful on something like x86 (or risc-v, now, with its compact
instructions). I much prefer it, but then I spend too much time in
assemblers.
Further, as Jacob mentions, alloca would require messing about with each
architecture, and Plan 9 has done such a good job of minimizing
architecture-specific code, it would be a shame to muddy it up.
Finally, note that the wider community has had an effort under way to
eliminate anything that looks like on-stack allocation and/or on-stack
arrays due to the prevalence of stack smashing. A quick search will find a
lot of material, but: gcc is working to help people claw their way back to
using only small fixed-size stack frames, which is where Plan 9 has been
all along. Bringing in alloca is moving in the wrong direction. I'd argue
that fixing Chez not to need alloca is a better approach.
Finally finally, if you *still* want something that looks like alloca, you
can do something like what we did in akaros (to bring in waserror, as it
happens): use spatch to rewrite the code such that this:
a = alloca(20);
becomes something like this:
if (waserror()) {
if (really) return error;
return 0;
}
a = malloc(20);
if (waserror()) free(a);
...
(at end of function)
error(0);
which will unwind the error stack and free things. Yes, nasty. It's kind of
a defer in C.
Note, that's not what we really did, just something like it, and not for
alloca; alloca is something you never want in a kernel.
Anyway, when I see comments such as: " (Why not add it?)", I want to
mention: some of these decisions are pretty subtle, and it pays to
understand why it is the way it is. People are too quick to assume there's
no reason, but there usually are several, and they've been with us for so
long we don't really think about them much any more.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-M5cda746b4e30afdd3368dd37
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
