Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac
Subject: Re: compiler thoughts
Message-ID: <21163@ucbvax.BERKELEY.EDU>
Date: Tue, 6-Oct-87 11:10:42 EDT
Article-I.D.: ucbvax.21163
Posted: Tue Oct  6 11:10:42 1987
Date-Received: Fri, 9-Oct-87 06:22:09 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 19

References:


Steve Falco pointed out that I'm missing the point in my recent
posting about 32k global limits in most C and pascal compilers on the
Mac. The problem isn't arrays, that are easy to program around, but
initialized data.  For example, on many systems bitmaps are passed
around as C source code that you are expected to compile into your
program. A single bitmap can easily be 1024x1024 bytes for a big
screen.

Because of the 32k global limit, few mac C compilers can compile
such a C source code fragment.

LightSpeed C already has a preamble that interprets a resource of type
'DATA' to set up the global area, and (if you are making a desk
accessory or actually any kind of code resource except an application,
it can generate code that references globals indirect off of register
a4 (which is initialized to point t a block of locked storage in the heap.)
instead of a5. It could easily extend the semantics of 'DATA'
resources to support an 'unbounded globals' option that did both these
things to get around any limits imposed by the environment.