Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!mcvax!ukc!acorn!ixi!clive
From: clive@ixi.UUCP (Clive)
Newsgroups: comp.unix.wizards
Subject: Re: alloca
Message-ID: <152@ixi.UUCP>
Date: 5 May 89 15:51:25 GMT
Reply-To: clive@ixi.uucp (Clive Feather)
Organization: none
Lines: 41
Summary:
Expires:
References:
Sender:
Followup-To:

I don't know where all this alloca stuff came from, but BCPL had a
nice function (I forget the name, but let's call it stack_malloc for now)
which called another function with an array of specified size on
the stack - thus when you left this function (*however* you did,
including longjumps), the array went away.

Translating to C, the definition would be something like:

      int stack_malloc (f, n)
      int (*f) (/* char [], int */);
      int n;
      {
          /* The body of this function is equivalent to the
             (illegal) code:

          char a [n];  /* This is illegal */

          return (*f) (a, n);
      }

[BCPL was typeless - it was much less painful]

The library code for this would do something like:
(assume args in r1 and r2, and ascending stack)

      r3 = r1
      r1 = sp
      sp += r2
      block copy the stack frame at fp (the one generated
        by the call) up by r2
      fp += r2
      /* the 'sp just before call' field in the frame is unaltered */
      jump @r3

I forget the return sequence used on this system, but this had the
right effect - the array was effectively in the caller's stack frame,
but when they returned, the sp had dropped down past it.
-- 
Clive D.W. Feather           clive@ixi.uucp
IXI Limited                  ...!mcvax!ukc!acorn!ixi!clive (untested)
                             +44 223 462 131