🚀 go-pugleaf

In article <46100070@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>a Mac program can't have a "code segment" longer than 32K, nor more
>than 32k of static data.  I had thought that the 68020 had a full 32bit flat
>address space, i.e. no segments at all.  This would seem to imply that I
>could write a program any size that will fit into memory; likewise for static
>(initialized) data.
>
>Doug McDonald (mcdonald @uiucuxe)

   This has to do with 68000 addressing modes.  For various reasons, the 680x0
is much more efficient when dealing with 16 bit displacements.  This is to say
that it's much faster to access data or make a program jump if you stay within
a 16 bit address displacement.  16 bits is equivalent to +/- 32K, so the
Macintosh requires that all program code be broken up into 32K blocks.  For
similar reasons, you have to stick with 32K of static data.
   This is not, in general, a big problem.  If you're using some high-level
language like C :-) or FORTRAN :-(, the effects of this are pretty much
transparent.  What you have to do is go through all of your source files,
and periodically insert statements to the effect of "segment initializer", or
"segment display_stuff", or whatever.  the MPW manual has all the details,
but assuming that your code comes in a number of reasonably sized files, this
is a pretty trivial procedure.
   Static data is slightly more tricky.  The easiest way to do this is
probably to dynamically allocate the memory you need for static data using the
memory manager, and then read the data in from a file.  Here is a skeleton
outline of approximately what you would do:
	instead of
		int my_big_array[50000];
	write
		int *my_big_array, myFile;
		my_big_array = NewPtr(50000 * sizeof(int));
		myFile = open("StaticData", INPUT);
		read(myFile, my_big_array, 50000 * sizeof(int));
		close(myFile);
	after this, you can use my_big_array just the way you did before.
You'll have to be virtuous about variable scope, error checking, and all the
rest of it, but this shouldn't be a big problem.  In my experience, it's well
worth the extra effort- my stuff on a MacII pretty much keeps up with our
SunIII/280 under unloaded conditions.  When the Sun gets busy (or goes down),
there's no comparison 8-).
   Hope this was helpful- email me if you have questions.
					-Matt

-- 
Matt Bamberger			"You think that because you understand _one_,
1005 E. 60th St., #346		 you understand _two_, because one and one
Chicago, IL 60637		 makes two.  But you must also understand
312-753-2261			 _and_."	-Sufi Master