🚀 go-pugleaf

Because of a bug in the old rom's resource manager, resources, including
code resources, could not be bigger than 32k.  As a result, most compilers
are poorly debugged when it comes to putting more than that amount of code
in a single segment.  

The Motorola 68000 processor itself compounds the problem by having
different rules for generating position independent code depending on
whether 16bit or 32 bit address offset instructions are used.

(Instances:, the T.M.L. Pascal Version 1.11 Linker
will generate incorrect code without even giving you a warning if you tell
it to put more than 32k code in a segment.  The Sumacc C cross development
system trys to handle the problem by not using the Mac Segment Loader,
putting all your code in one block, and patching refernces itself at load
time to try to get you position independence.  This scheme almost works -
it fails for desk accessories like Calendar, since in a desk accessory
the application is free to move around the code of the desk accessory
whenver the desk accessory is not being run.  Since relocation happens
only when the desk accessory comes in from disk running the moved,
in-memory copy causes a bomb.  Setting the "needs lock" bit cures the symptom,
but not the problem of bad code generation.)

Breaking a program up into segments seems straight-forward, but it has its
own set of pitfalls.  The big one is that before the break-up all the
procedures in the program were in the same segment.  Afterwards, an
ordinary procedure call might cause the heap to get re-arranged.  
My example of this bug uses a source of segmentation that happens all the
time, but that most programmers don't think about:  Whenever you call a
routine in a package, you have the same potential for disaster that you
have when you call a routine in a different segment.

Example:
PROCEDURE Bomber;
VAR h : Handle;
BEGIN
  h := GetDataHandleProcedure;
  Qsort(h^, 0, GetHandleSize(h) div DATAITEMSIZE, @IUCompString);
END;
This bombs some of the time because when Qsort calls IUCompString,
IUCompString is going to call the International Utilities Package.
The package will be read in from disk if it is not already resident.
The resource manager will call the memory manager to get room to put the
package.  The memory manager might reshuffle the heap, and if it does,
h^ will no longer point at the data.
(Before the current release of the software, the Pascal version of IUCompstring
incorrectly failed to save register A3, but that is another problem.)

The solution is simple: Use MacroScope to:
1.) prowl the source code files that make up a program to produce a text file
containing the calling tree of the entire program (a graph of what calls
what for the entire program.)
2.) resolve the calling graph against the linker source file to discover
what calling chains might potentially cause problems due to heap shuffling
and un-locked pointers.
3.) examine the actual calls to determine whether the arguments are locked
or not.  (Throw out those lines where it is easy to tell that all the
arguments are non-moveable.)
4.) produce an error message file containing only those lines that might
cause problems.

Unfortunately MacroScope hasn't been released for sale yet.

--- David Phillip Oster		-- "The goal of Computer Science is to
Arpa: oster@lapis.berkeley.edu  -- build something that will last at
Uucp: ucbvax!ucblapis!oster     -- least until we've finished building it."