Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!keith
From: keith@Apple.COM (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mac C Compiler?
Message-ID: <45213@apple.Apple.COM>
Date: 27 Sep 90 06:43:12 GMT
References: <1990Sep24.184845.12502@ux1.cso.uiuc.edu> <1990Sep26.225549.17792@midway.uchicago.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 75

In article <1990Sep26.225549.17792@midway.uchicago.edu> francis@arthur.uchicago.edu (Francis Stracke) writes:
>In article <1990Sep24.184845.12502@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>>
>[...]
>>I tried compiling this on the Mac with a borrowed copy of Lightspeed C
>>and it failed. These are large programs - a couple of megabytes
>>of global data and several very large subroutines (that compile to
>>somewhere between 50 and 125 kbytes of code on varying computers).
>>Lightspeed C apparently thinks it is too big.
>
>Damn straight, it's too big! Macs use a variety of segmenting that puts each
>segment of your program into its own code resource (if you don't know, don't
>worry).  No resource can be bigger than 32K (theoretically--I've seen some
>sound resources get around it somehow--but it's probably tricky and risky
>enough that no compiler would do it, especially with work-arounds available--
>see below).  No subroutine can be spread across more than one segment
>(reasonable, no?).  Therefore, no subroutines over 32K.
>
>What you need to do is break up those subroutines, so that their pieces come out
>less than 32K each, then put pieces into separate segments.  What are
>you doing with routines that big, anyway? What's the point of structure?
>
>BTW: the reason resources aren't supposed to be over 32K is that their sizes are
>expressed as integers (maxint=32767).

Francis,

Go to jail, do not collect $200. Your conclusion was correct (that the
limit on code segments and procedures is generally 32K), but your
reasons are wrong.

First of all, there is no theoretical reason why resources cannot be
larger than 32K. Looking on page I-129 of IM, you'll see in the middle
of the page that resource lengths are stored as 4 bytes - a long int.
However, if you flip the page to I-130, you'll see a line describing a
3 byte entry. This three byte entry is an offset to the resource being
referenced. This limits the size of your resource fork to around 16Meg.
Hence, the largest resource you can have is actually a function of how
many resources you have. If you have only one, then you should be able
to get it pretty close to 16Meg (yes, you, too, can try this at home
on your 16Meg Macintosh).

So where did this lore of resources being 32K or smaller come from.
It's because of a bug in the 64K ROMs. As I recall, there were problems
with handling resources in the even 32K banks (i.e. 32K-64K, 96K-128K,
etc.).  However, this was fixed over 4 years ago with the 128K ROMs.
(The details of this could be off a little, but I think that's the gist
of it. Feel free to correct me if I'm wrong.)

On the other hand, there is still a practical limit of 32K on CODE
resources, which hold your program's object code. This is because of a
limitation in the 68000. Code in the Macintosh architecture needs to be
relocatable, which means no absolute address. This leaves us with being
able to use only PC-relative address modes for branching. And the only
PC-relative address modes use 16-bit signed offsets. This gives a
range of 32K in either direction. This is what gives us our limitation
of 32K in CODE resource (the code at the beginning of the segment has
to be guaranteed to reach a procedure at the end).

Similarly, we have our limitations on global variable space and jump
table size. Both of these are reference with the A5 register. The
global variable space comprises the 32K below A5, and the jump table
takes up the 32K above A5.

Now, some of this can be worked around by the enterprising hacker,
but not by the faint of heart. But for those of you with the patience
and the bucks, MPW 3.2 will go a long way towards abolishing those
limits for once and for all.

-- 
------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions