Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re: C stack frame sizes
Message-ID: <6255@brl-tgr.ARPA>
Date: Fri, 30-Nov-84 20:17:20 EST
Article-I.D.: brl-tgr.6255
Posted: Fri Nov 30 20:17:20 1984
Date-Received: Sun, 2-Dec-84 05:38:18 EST
References: <18092@arizona.UUCP>
Distribution: net
Organization: Ballistic Research Lab
Lines: 18

> Has anyone ever empirically studied the sizes of C stack frames for UNIX
> applications?  The particular question I have is:  How serious would a
> 65kbyte maximum frame size be for a 32 bit machine.

I have recently had some practical experience with this issue.  On the
Gould UTX-32 system (and I believe on IBM 370s too), the architecture
rather strongly encouraged the C/UNIX implementors to use a relatively
small chunk of address space for the run-time stack.  The exact amount
can be adjusted when one link-edits a binary executable image; using
around 24Kb worked well for nearly all UNIX System V utilities.  64Kb
would probably suffice for almost all applications; those having trouble
most likely could be fixed by changing large "auto" arrays to "static".
I have yet to see a practical example where a huge amount of recursion
was required; however, if one turned up, it would not be easy to fix.

So a SINGLE stack frame limit of 64Kb would certainly not be very
troublesome.  I imagine someone has written code that needs more, but
they have already severely limited their target machine choices.