Function: allocatemem
Class: gp
Section: programming/specific
C-Name: allocatemem0
Prototype: vDG
Help: allocatemem({s=0}): allocates a new stack of s bytes. doubles the
 stack if s is omitted.
Doc: this very special operation
 allows the user to change the stack size \emph{after} initialization. $x$
 must be a non-negative integer. If $x \neq 0$, a new stack of size
 $16*\ceil{x/16}$ bytes is allocated. If $x=0$, the size of
 the new stack is twice the size of the old one. The old stack is discarded.

 \misctitle{Warning} This function should be typed at the \kbd{gp} prompt in
 interactive usage, or left by itself at the start of batch files.
 It cannot be used meaningfully in loop-like constructs, or as part of a
 larger expression sequence, e.g
 \bprog
    allocatemem(); x = 1;   \\@com This will not set \kbd{x}!
 @eprog\noindent
 In fact, all loops are immediately exited, user functions terminated, and
 the rest of the sequence following \kbd{allocatemem()} is silently
 discarded, as well as all pending sequences of instructions. We just go on
 reading the next instruction sequence from the file we're in (or from the
 user). In particular, we have the following possibly unexpected behavior: in
 \bprog
    read("file.gp"); x = 1
 @eprog\noindent were \kbd{file.gp} contains an \kbd{allocatemem} statement,
 the \kbd{x = 1} is never executed, since all pending instructions in the
 current sequence are discarded.

 The technical reason is that this routine moves the stack, so temporary
 objects created during the current expression evaluation are not correct
 anymore. (In particular byte-compiled expressions, which are allocated on
 the stack.) To avoid accessing obsolete pointers to the old stack, this
 routine ends by a \kbd{longjmp}.
