This file contains a list of the things which I know must be changed in
order for BIG LEAP at CASE (with 2↑27 possible items) to be compile, and
runable.


1. MATCHING PROCEDURE ? PARAMETERS - stack entry currently contains
	

	1. (? parameter bound) - the item bound to the parameter

	2. (? parameter unbound) - left half has @ bit on, rh has
		the address of the itemvar parameter.

    LOADING - thus to load into AC the current item value of the parameter

		MOVEI AC,@STKPOS(F)

    ADDRESS - to calculate the address of the ? parameter (for storing,passing
	as reference parameter)

		MOVE	X,STKPOS(F)	;ASSUME THAT WAS UNBOUND
		TLZN	X,20		;TEST ASSUMPTION
		MOVEI   X,STKPOS(F)	;ASSUMPTION WAS INCORRECT

    Suggested fix:
	use sign bit instead of @ for indicating address rather than value
	is on stack

	1. (? parameter bound) - same as above
	2. (? parameter unbound) - lh has bit 400000, 	rh has address of
		the itemvar parameter


    LOADING- thus to load into AC the current item value of the parameter

		SKIPG   AC,STKPOS(F)
		MOVE	AC,(AC)

    ADDRESS - to calculate the address of the ? parameter (for storing etc)

		SKIPL	AC,STKPOS(F)
		MOVEI	AC,STKPOS(F)

    The above change would necesitate changes in GENMOV(GET)
        GENMOV(GET,ADDR), GENMOV(PUT), PREPAR(LEAP), GETITM(LEAP)
	And FORGO (inside LEPRUN where locals are placed in the SCB)
    Check cref's for other places(look for MPBIND)

2. Other limits caused by 27-bits
    a. FOREACH interpreter
		MC,MB  byte pointers
		SCB in general since can no longer store 2-items in a single word

    b. DATM, INFTB
3. DATUM PROBLEMS - 
	For complicated datums (arrays, lists, sets , strings) we must have
	a way of making sure that the storage allocated for them lie in the
	same "page" as the "datum". This will cause all sorts of difficulties
	as their "addresses" are not conformable with other SAIL "addresses"
	And it looks as if each routine will have to be dynamically 
	interpreted with execution dependant on whether the arguments and
	results are datums of items (thus very large portions of the
	runtime system would have to be rewritten) (all the array munging
	code, string stuff, sets and lists etc.
3. Context mechanism - for datum. will have to have special descriptor code
	if a context item, will have to get space from different spot.

4. In general -how do you determine how to obtain list space (to avoid clanking)
	also don't want stuff on disk refering to core addresses etc.