Proposal  #2



Stack Groups on the Falcon.


	The hardware stack structure on the Falcon is different than that
on the lambda.  However, what the programmer wants to see (from the debugger, for
example) remains the same, a "stack machine".   This proposal details how we
reformat the various falcon stacks into stacks which look very much like the LAMBDA.
The basic idea is to the reformatting always and at the very lowest level,
i.e. as the data is loaded or stored from the falcon hardware.

Doing it this way has several advantages and disadvantages.

advantages:
     (1)economy of mechanism-- no need for separate "scrolling" routines for example.
	     no matter what you are trying to do, you save out, do-it, and reload.
	     Thus, the only routines deal directly with the hardware are load and store.
     (2)minimum of code that runs in "embarrasing" circumstances
	     Somewhat a consequence of 1.  When the Falcon call hardware is "disturbed"
	     the code must VERY careful.  (no ordinary subroutines, may not be able to
	     reference local variables in the usual way, etc .)  Ultimate reliability
	     will be served if this sort of code is minimized.
     (3)avoid proliferation of hardware frame numbers into system datastructures.
	     the HEAP numbers used by the falcon hardware may cause difficulties if
	     they are allowed to "persist" over a long period.  (When you reload they
	     might not be the same, what if you have to scroll, what if there are more than
	     256 frames, etc. etc.)  We avoid these difficulties by discarding them
	     immediately (remapping them, if you will, into positions in a conventional
	     lambda style stack.).
     (4)closest to lambda.
	     This will allow our current error handler to operate with minimum modification.


disadvantages:
	some loss of efficiency
	     doesn't make "pooled" use of hardware  (i.e. allowing several processes frames
		to be in hardware at once.)  This is probably not a good idea anyway for various
		reasons. However, a slight inefficency will occur.  Process switch time will
		still be quite acceptable (by lisp machine standards) anyway.
	     normal stack group switch
		a small overhead may occur due to this mapping, etc, as compared to simply
		storing out the hardware in a fixed place, etc.   This is insignificantly
		small and may not ever exist since the code required is comparable.
	     catch and throw.  Storing things out and reloading to implement "stack molesting"
		operations could introduce some overhead.  The case which we might eventually
		want to fix by a "fast bypass" is short THROWs.  If you are THROWing to a place
		only a few frames up the stack, it will be quite a significant overhead to 
		store out the stack group, figure out the THROW, and reload.  This can be fixed
		"looking" for the catch
can be fixed by  "fast bypass" for simple cases.
		

shortcommings:  (due to fleabit)
	due to the lack of formatting information in fleabit format stacks,
some debuggor operations will not be possible.