Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!cyklop.nada.kth.se!news
From: d88-jwa@dront.nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mac C Compiler?
Message-ID: <1990Sep27.170630.19937@nada.kth.se>
Date: 27 Sep 90 17:06:30 GMT
References: <1990Sep24.184845.12502@ux1.cso.uiuc.edu> <1990Sep26.225549.17792@midway.uchicago.edu>
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 25

In article <1990Sep26.225549.17792@midway.uchicago.edu> francis@arthur.uchicago.edu (Francis Stracke) writes:

>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

>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?

Such nonsense ! Resources can be as big as you like. Sizes are longints
and have been since version 2 of the system (or something thereabout)
It's just that the 64k ROMs had a few bugs in them...

CODE resources and ststic/global data can't be larger than 32k because
the compiler uses 16-bit offsets (much faster and more efficient)

I believe there is a version of MPW C (3.1 ?) that lets you make it
generate 32bit references, and thus get around the limits.

(16bit offsets are made because all code on the mac is relocatable)

							h+
	Jon W{tte, Stockholm, Sweden, h+@nada.kth.se