scope of malloc

[Richard A. O'Keefe]

In article <14448 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
: In article <3739 at skye.ed.ac.uk> richard at aiai.UUCP (Richard Tobin) writes:
: >Are there *any* widely-used processors that can't implement alloca()
: >reasonably efficiently even with compiler support?

: It can't be implemented correctly (except by the compiler turning it into
: malloc()/free() calls that you could have coded yourself) on any system
: that doesn't provide separate frame and stack pointers.  Just consider
: the effects of an interrupt.  It also cannot be reasonably implemented on
: a system that uses linked stack frames, such as on the IBM System/370.

Surely the significant part of Richard Tobin's posting was the
magic phrase EVEN WITH COMPILER SUPPORT?

Algol 60 compilers, Algol 68 compilers (_love_ that Algol 68C), Simula 67
compilers, PL/I Fortran 90 compilers, Ada compilers, *all* have to be able
to do what is required.

One method:
    have an "aptovec stack" as well as the procedure call stack,
    dedicate two slots in the frame of a function IF that function
    calls alloca().
	function entry:
		alloca_frame_link = global_alloca_link;
		global_alloa_link = &alloca_frame_link;
		alloca_frame_save = alloca_stack_top;
	function exit:
		alloca_stack_top = alloca_frame_save;
	call x = alloca(n)
		alloca_stack_top = n + (x = alloca_stack_top);
    longjmp() unwinds the linked list of frames, resetting alloca_stack_top
    as it goes.

If it is possible to set aside an area of VM for this, that's all you need.
If you need to allocate the "aptovec stack" in chunks, it gets a bit harder,
but not much.

This message should not be taken as endorsing the alloca() interface as such.
-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.