Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mp From: mp@allegra.UUCP (Mark Plotnick) Newsgroups: net.lang.c Subject: Re: C stack frame > 64K (on a Sun) Message-ID: <2951@allegra.UUCP> Date: Tue, 11-Dec-84 11:18:05 EST Article-I.D.: allegra.2951 Posted: Tue Dec 11 11:18:05 1984 Date-Received: Wed, 12-Dec-84 04:14:17 EST References: <18092@arizona.UUCP> <6255@brl-tgr.ARPA> <1837@sun.uucp> Organization: AT&T Bell Laboratories, Murray Hill Lines: 64 > From gnu@sun.uucp (John Gilmore) > The Sun C compiler used to have this restriction. We fixed it. It was easy > (on the 68000). Hey, all you people who "severely limited their target > machine choices" -- your code will run fine on Suns! Note that if you care about getting correct code out of the SMI C compiler, you shouldn't use stack frames larger than 32Kbytes. This is because of a bug in their compiler (at least as of release 1.1, which is what we have) with the handling of floating point operations that require scratch areas on the stack. The compiler doesn't seem to know that displacements, as in reg@(disp), are limited to 16-bit signed integers. Example: calliope% cat bug.c #ifndef SIZE #define SIZE 30000 #endif #includemain() { char HIGHBOUND; double tx,temp; char c[SIZE]; int lcv, i; char LOWBOUND; printf("&LOWBOUND=%d &HIGHBOUND=%d\n", &LOWBOUND, &HIGHBOUND); printf("stack size = approx %d\n", &HIGHBOUND - &LOWBOUND); fflush(stdout); for(i=0;i