Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!xanth!ames!claris!wombat
From: wombat@claris.com (Scott Lindsey)
Newsgroups: comp.sys.apple
Subject: Re: large GS programs in APW C
Message-ID: <9124@claris.com>
Date: 21 Mar 89 07:59:43 GMT
References: <8903201806.aa11426@SMOKE.BRL.MIL>
Organization: Claris Corporation, Mountain View CA
Lines: 55

From article <8903201806.aa11426@SMOKE.BRL.MIL>, by AWCTTYPA@UIAMVS.BITNET ("David A. Lyons"):

> About APW C (and/or MPW IIgs C?):
> 

> The 64K limit applies only to SIMPLE STATIC variables, right?  (Not
> to arrays or to auto variables.)  I have a hard time imagining how
> to use up all 64K.
OK, arrays go into ~arrays.  Locals are allocated on the direct page.
Any other variables are in ~globals (globals, static globals & static locals).
I assume APW C is this way as well (I've forgone it for MPWIIGS C).  
 
> Desktop programs like AWGS (or anything that lets you work with
> multiple documents) doesn't need much global data anyway--just
> allocate whatever you need from the memory manager when it's needed.

I really wasn't referring directly to AWGS...
I don't know how much non-dynamic space AWGS uses (static is a poor term
here, because it means something different to C than it does to the loader),
especially if you add up the 6 modules and all the internal stuff.  What's
really bad is that the 6 modules are all (mostly) dynamic.  If it were done
in C using the 1 data bank scheme, all the non-array variables for every
module, loaded or not, would have to be loaded all the time.  Yes, you can
start using a multi-bank scheme, but that's where it starts getting messy,
especially if you mix in assembly code.

 
> Does something come out of that 64K that I'm forgetting?

Initialized variables, maybe?  The only thing that goes in ~arrays are
arrays.  I assume by auto variables you mean auto-initialized variables?
They go right in ~globals too.

Don't get me entirely wrong.  C is my choice of languages to program in.
C for the GS, though, does not lend itself to major applications.  You
have to be intimately familiar with the architecture, and you have to
mix assembly or use it inline.  BTW, there is code you cannot generate
using inline assembly, (such as self-modifying code - which does have its
uses sometimes).

If I were to start developing a program for the GS right now, I'd use a mix
of C, inline assembly, and assembly, but still not be entirely happy.  For
anyone not familiar with the GS and 65816, my advice is to start in assembly,
learn it well, then use C later on when you know how to mix and match the
two.  I am not very familiar with the Pascal for the GS.  I much prefer
C over Pascal, incidentally, but I seem to recall that GS Pascal generates
generally more efficient code that C does.



-- 
Scott Lindsey     |"Cold and misty morning. I heard a warning borne in the air
Claris Corp.      |    About an age of power when no one had an hour to spare"
ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple,
wombat@claris.com |    StyleWare, the author, or anyone else living or dead.