Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C 32K global data limit: workaround?
Message-ID: <33283@ucbvax.BERKELEY.EDU>
Date: 18 Dec 89 16:50:39 GMT
References: <257@intek01.UUCP>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 68

In article <257@intek01.UUCP> mark@intek01.UUCP (Mark McWiggins) writes:
_>We're getting discouraged with the speed of MPW C (especially with C++)
_>and are interested in evaluating Think C as a target for C++ 2.0. 
_>But the 32K global data limit is a concern.  Has anyone come up with 
_>a satisfactory workaround?

It is easy if you are writing a C++ to C translator: Just write your
static data into a resource, and generate code to read in the resource at
program initialization time, and reference the globals off of it:

example, a c++ program:

char *banner = "Hello World\n";
main(){
	printf(banner);
}

------------
generates two files: an Rmaker or Rez file with the globals in it
(I'll use RMaker here, because I know it better.)
a.out.rsrc
????????

Type Glob=GNRL
  ,129 (4)
.S
Hello World\0A

------------
and the following .c file:

Ptr __global;
#define __BANNEROFFSET 0
main(){
	Handle __globh;
	if(NULL == (__globalh = GetResource('Glob', 128) )){
		fprintf(stderr, "No Global Resource!\n");
		exit(-1);
	}
	MaxApplZone();
	MoveHHi(__globh);
	HLock(__globh);
	__global = *__globh;

	printf( (char *) (__global+__BANNEROFFSET) );
}

Notes:
We get at globals by doing explicit pointer arithmetic in case THINK C has
restrictions on how big a single struct can be. We initialize __global
once, at the beginning of the program, and after that, it is initialized:
we can just use it as a global base pointer after that.

We call MoveHHi() since the global data handle will be locked for the
entire duration of the program, and we don't want it cluttering the heap.
The call before it make sure it really goes at the _end_ of the
heap. If your translator gives the user control over the amount of program
stack space, you'll want to put a SetApplLimit() before the
MaxApplZone().

The above scheme will work even if you write interrupt level callback
routines in c++, since they will have to set up their own A5, as usual,
and after that, the translated access to globals will work the same as it
does in an application.

--- David Phillip Oster            --  No, I come from Boston. I just work
Arpa: oster@dewey.soe.berkeley.edu --  in cyberspace.
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu