Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ritcv.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!rochester!ritcv!mjl
From: mjl@ritcv.UUCP (Mike Lutz)
Newsgroups: net.lang.c
Subject: Re: C stack frame sizes
Message-ID: <1413@ritcv.UUCP>
Date: Sun, 9-Dec-84 17:24:05 EST
Article-I.D.: ritcv.1413
Posted: Sun Dec  9 17:24:05 1984
Date-Received: Tue, 11-Dec-84 03:21:01 EST
References: <2400@pur-ee.UUCP>, <1397@ritcv.UUCP> <4739@utzoo.UUCP>
Organization: Rochester Institute of Technology, Rochester, NY
Lines: 22

>> ... does the Berkeley RISC require a parallel stack,
>> maintained by software protocols, to hold structures, arrays, and other
>> humongous local variables?
>
>The RISC needs a memory stack anyway, because of the possibility that the
>"register stack" will overflow.

True, but the memory overflow stack is basically a 'shadow' of the
register stack, or, alternatively, one can view the register stack as a
cache for the most recently activated procedures.  The original RISC-I
papers from Berkeley imply this when discussing the software handlers
for register stack overflow/underflow.  Note that the plan to have the
registers addressable as memory locations agrees with the shadow/cache
model.

However, since the idea the register stack is designed for scalars and
pointers, I still think there is a need for a separate stack for large,
automatic, data structures - no?
-- 
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{allegra,seismo}!rochester!ritcv!mjl
CSNET:		mjl%rit@csnet-relay.ARPA