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.
     (5)only two stacks need be allocate (or worried about) in most contexts, as on LAMBDA.
	     (these are the MAIN and SPECIAL stacks).  Only one EXTRANEOUS stack per entire
	     system is allocated, and it is considered to be in the same logical classification
	     as the hardware stacks.

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 sped
		back up by an "fast case" test which looks for the catch frame within the FALCON 
		call hardware.  If found, it would do the right thing, etc.  If the catch-frame
		was not found, then you store out etc.  Note that in any case it is necessary for
		the system to be able to handle the case where you are throwing over more frames
		than will fit in the call hardware (no matter how big that might be unless it was
		capable of being truly arbitrarily large).
	    Copying data  in the EXTRANEOUS stack.  Since the EXTRANEOUS stack is considered to
		be on a level with the hardware stack(s), it is emptied and/or reloaded in parallel
		with the actual hardware.  This data might not need to be copied otherwise.  However,
		the overhead should not be significant since if you are using the extraneous stack,
		you are not running ultra fast anyway.  (note that it is not necessary to reload
		the "entire" EXTRANEOUS stack (if that were defined somehow) but only that portion
		that corresponds to the portion loaded in the PHYSICAL call hardware.

shortcommings:  (These dont really have to do with the scheme being proposed here, but are due
		to inherit design deficiencies in FLEABIT.  However, we might as well discuss them
		here.)
		Due to the lack of formatting information in fleabit format stacks, it may not be
		possible to put information in the FLEABIT BIND and EXTRANEOUS stacks in their
		proper frames on "stack group" stack.  Until this is fixed, it will not be