Path: utzoo!utgpu!watserv1!watmath!att!cbnewsk!ech From: ech@cbnewsk.att.com (ned.horvath) Newsgroups: comp.sys.mac.programmer Subject: Re: global data in Think C Message-ID: <1990May26.160441.15583@cbnewsk.att.com> Date: 26 May 90 16:04:41 GMT References: Organization: AT&T Bell Laboratories Lines: 36 From article , by cc4b+@andrew.cmu.edu (Christopher Brian Cox): > Rich, > > Face it, the 32k global data limit is a BUG! > I have a little program here called p2c. It had 90+k of global data > when I first compiled it. After removing the un-initialized arrays > and allocating them at runtime, it had 48+k of global data. > That's with Seperate STRS. > The compiler should automatically allocate un-initialized arrays at > runtime. There still shouldn't be a 32k limit. > > Chris Cox Ease off. 32K is a restriction, an irritation at worst. It is routed in the fact that the MC68000 uses 16-bit signed offsets for address-register based addressing, and furthered by Apple's decision to use a program model that includes "globals are accesssed as negative offsets from a5." There are ways around this for the compiler writer, but because of the inherent limitations of the processor chip, they all require explicit address arithmetic in the generated machine code. That means larger, slower programs. You have a couple of alternatives. One you've identified: using NewPtr or NewHandle at run time for uninitialized arrays cut your "globals" requirement in half. That has the rather nice side effect that you can resize such arrays to match the problem size. For large initialized arrays, consider "compiling" them into resources, or reading them in from your data fork. I won't argue that this is convenient, and you might justifiably claim that Motorola, Apple, and Think/Symantec have made your life a little tougher. The only compiler I know of that lets you duck the limit (for a price in speed and size) is Aztec C. =Ned Horvath=