From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 28 Sep 93 12:08:10 GMT
From: noc.near.net!das-news.harvard.edu!honeydew.srv.cs.cmu.edu!bb3.andrew.cmu.
edu!news.sei.cmu.edu!firth@uunet.uu.net  (Robert Firth)
Subject: Re: GNAT & Unconstrained Arrays
Message-ID: <1993Sep28.080810.15779@sei.cmu.edu>
List-Id: <comp.lang.ada>

In article <CE1vHy.4C4@inmet.camb.inmet.com> stt@spock.camb.inmet.com (Tucker T
aft) writes:

>The Intermetrics Ada compilers generally use a "secondary stack" for
>objects whose size is not known at compile-time, as well as for
>returning from functions with unconstrained result subtypes.
>A secondary stack is simply a per-task mark/release heap.

I have used exactly this system in two language implementations, and
strongly recommend it.

Some advantages, briefly:

(a) the primary stack size is known at the function level at compile
    time.  This not only saves a register, it simplifies both variable
    addressing and variable allocation.  For example, you don;t have
    to float simple variables out of inner blocks.

(b) the register you save can be the secondary stack pointer, and the
    mark/allocate/release then becomes simple open code

(c) the secondary stack is per task.  You don't have to worry about
    interrupts and task context switches during variable allocations -
    NEW must still implement mutual exclusion (or hairy tricks), but
    nothing else has to

(d) within a task, you have substantial gains in data locality

(e) you have much more freedom when and how to implement the release,
    since you know that the allocation is (almost) strictly LIFO and
    contiguous.  For example, you can release all the dynamic memory
    on function exit with one instruction, since you know there has
    been no task interleaving fragmenting a global heap.

In my humble opinion, putting local objects onto a global heap almost
always causes more trouble than it's worth, and leads to a series of
ever hairier, more dubious, and less maintainable hacks.

Robert Firth