Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!eos!ames!elroy!cit-vax!tybalt.caltech.edu!wetter
From: wetter@tybalt.caltech.edu (Pierce T. Wetter)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Goin' Crazy on a Mac, or, How I Love MPW "GlobalData"
Message-ID: <6333@cit-vax.Caltech.Edu>
Date: 1 May 88 08:25:06 GMT
References: <4625@batcomputer.tn.cornell.edu>
Sender: news@cit-vax.Caltech.Edu
Reply-To: wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter)
Organization: California Institute of Technology
Lines: 75

In article <4625@batcomputer.tn.cornell.edu> garry@oak.cadif.cornell.edu writes:
>We have worked around the bugs in Quickdraw, the obscurities in the
    What bugs?
>The MPW C compiler is not very good, but unfortunately it is Apple's
>choice, so it has to be the primary focus of our Mac support. MPW C
>has the custom of loading the A5 register with a pointer to all of
>"global data" during program start-up. All accesses are then via a
>15-bit offset to A5, which never changes.  ("Global data" consists of
>everything that's not code and not dynamically allocated - global
>variables, static variables, strings, and floating-point constants (12
>bytes each!).)   The bottom line is that with MPW you can only ever
>have 32K (2^15) of fixed data. Doesn't matter if your Mac has
>megabytes and megabytes of memory; 32K is the static data limit. 
   Actually this is common to all languages under MPW. Global data is
referenced as an offset from a5. On the 68000 thats 16 bits, on the 020 its
32 bits. Read the object code format description if you want more details.
I agree it can be annoying, but there are some things to remember.

      1. Static variables consist of a bunch of DC.L statements. Therefore
          20K of empty static arrays will take up 20K of disk space.
      2. Quickdraw globals have to be addressed this way anyways.
>
>Question 1:
>        Anybody know of any magic workarounds to this limit, short of
>        damaging all of our source code? 
   If its for a 68020 machine, you might be able to ignore the messages
produced by link, but don't quote me.
	
>Question 2: 
>	Has anyone heard any rumors that this MPW bug might be fixed
>        sometime soon? (There's a rumored "3.0" release coming, but as
>        far as we can tell a "32K" fix is not included in it.) 

>Question 3: 
>        We *might* be able to squeeze our own data into 32K, but the
>        user program that links to our library would surely push
>        things back over the limit. If we could separate the user's A5
>        usage from our library's, then we might be OK. Has anyone ever
>        gone through the exercise of segmenting a program into *multiple
>        separate code resources* on the Mac?  (The system apparently
>        does this all the time, but the details of the "message-
>	passing" involved are obscure to us.) 
    Segmenting a program simply requires a "#define ___SEG___ segname" message.
All procedures following such a message will be placed in 'segname' by the
linker.
   This won't help anyways. The real problem is that the 68000 can only have
a 16 bit offset from a5. Note that the limit should be 64K and a5 should point
to the center of your data, but no compiler writers are smart enough to think
of that.
   As for your data, you're probably allocating large arrays. Why not just 
allocate a pointer and write some initilization code to allocate the space
at startup. Since this is a library you might want to do the following:

Replace
static double  MEMORY[10000000000]
with
static double *MEMORY=0;


{ 
if (MEMORY=NULL) MEMORY=malloc( 10000000000* sizeof(double))
 MEMORY[5]=PI;
}

>(Good ideas unfortunately do not automatically make a system "programmer 
> friendly". "Ghetto" debugging, complicated data structures, no error 
> checking, and no error messages - Apple, you're a bunch of nitwits!)
    They do give you the number though, you just have to look it up.
 (If its listed. My Favorite Unlisted Error: -4001, LaserPrinter out of Paper)

Pierce Wetter
----------------------------------------------------------------
wetter@tybalt.caltech.edu     Race For Space Grand Prize Winner.
-----------------------------------------------------------------
   Useless Advice #986: Never sit on a Tack.