🚀 go-pugleaf

GNUish MSDOS code (extremely useful stuff) 
often compiles nicely under Turbo C
(though the port was apparently done for MS-C), except it
frequently uses alloca(), which is supposed to get
new memory in the current stack frame.  The memory
is supposed to be automatically freed when the current
 { ... } block (or at least the current function call)
closes.  So far I've been able to get bison and flex (GNU's
yacc and lex) to compile by faking alloca() with malloc(), but
it's a pain to ensure that free() is called correctly, and of
course free() is time-consuming in an inner loop because it has
to merge free blocks, etc.

The question is whether I can get away with writing my own
alloca().  Allocation seems pretty easy.  SP points to the last
loc in use on the stack, so (without checking for alignment,
overflow, etc.) we can get _cdecl near void *alloca(unsigned n)
with something like:

alloca	proc near
	pop bx			; get return address
	pop cx			; get n
	sub sp,cx 		; allocate space on stack
	mov ax, sp		; set up return pointer
	sub sp, 2		; compensate for caller's increment
	jmp bx			; return
alloca 	endp

The problem is with deallocation.  WILL IT ALWAYS BE DONE BY
CODE GENERATED BY TC?  Things are fine with the `normal' activation
protocol: push bp; mov bp,sp; sub sp,?  ...  mov sp,bp; pop bp; ret
A possible bad case is if Standard Stack Frame is Off.  Then this
protocol can be skipped entirely and mucking with SP is disaster.
I'm asking those who are really familiar with the TC's code generator 
if they know of other dangers e.g. functions with no locals,
tail calls, nested blocks with locals, and so on.  Of course a
working alloca() would be even better (-8 .

Gene Ressler