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