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

#include 

main()
{

	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