Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcnc!gatech!rutgers!dayton!mmm!olson
From: olson@mmm.UUCP (Al Olson)
Newsgroups: comp.sys.mac
Subject: Re: turning off the stack sniffer (long)
Message-ID: <1370@mmm.UUCP>
Date: Tue, 7-Jul-87 15:36:12 EDT
Article-I.D.: mmm.1370
Posted: Tue Jul  7 15:36:12 1987
Date-Received: Sat, 11-Jul-87 00:43:34 EDT
References: <1289@briar.Philips.Com> <135@cantuar.UUCP>
Reply-To: olson@mmm.UUCP (Al Olson)
Organization: Software & Electronics Resource Center/3M
Lines: 50
Keywords: stack 60 Hz multitasking HeapEnd trap dispatcher dirty illegal
Summary: There is another way... (long)


I have also been playing around with "multi-tasking" on the Mac and
ran into the some of the same problems.  I discovered that placing a
process stack in a heap block causes major-league problems. (The
MoreMasters trap also looks for heap zones on the stack in its
search.  Blammo!)  This approach gave me so much grief that I did
the only logical thing -- I gave up.

Well, not completely.  The Mac firmly believes that the stack is the
stack and the heap is the heap, so why fool it?  I tried another
approach which works faily well - link the process stack on to the
scheduler stack a context switch.  Where does it come from?

When a process is prempted (either synchronously or asynchronously),
copy the process portion of the stack (including registers, etc) into
a newly allocated heap block.  Then save the handle in the process
descriptor.  Now deallocate the process stack and restore the scheduler.
This is nice because when a process is not executing its saved stack
relocates in memory.  When resumeing a process, do the reverse: create
space on the scheduler stack, copy the proc stack in and throw the block
away. (of course you have to lock the handle during transfer).

This method has the advantage of keeping the stack and the heap seperate
and allowing the stack sniffer to work *for* you.  The disadvantage is
the increased time to perform a context switch.  (the BlockMove trap
is pretty damn fast though).

Process premption and toolbox reentrancy is another issue, however.
I approached this in a slightly different, but equally illegal way.
After a few sessions with Tmon, I discovered the format of the stack
during the execution of a VBL task.  Way down deep, but in a fixed
location, lie the SR and PC value pushed during the exception by the
68000.  Now what?  Prior to entering the scheduler, I located and
locked the resource map for the application (scheduler + processes)
ank kept a pointer to the CODE resource list.  During my VBL task
I compare the interrupt PC value with all loaded code segments.  If
the PC lies in a loaded CODE segment (not the scheduler's, however)
then I *replace* the interrupt PC and SR with my own premption routine.
(after saving them, of course).  The result: asynchronous premption.

The only real advantage of this method is that I have not patched
*any* trap routine.  (although blasting the stack is certainly more
severe)  I guess there is no easy way to initiate asynchronous premption
without resorting to subterfuge...

Any way, these are just some thoughts I had on the subject.  Maybe
I should wait for a Mac II and Unix...
-- 

Alan Olson	ihnp4!mmm!olson