--- /dev/null
+Description of applicat.scm
+
+Purpose:
+--------
+APPLICAT examines CALLs and rewrites them into calls to
+pseudo-primitives if the operator is not know. (using %internal-apply)
+In a few cases the CALL is not rewriten: QUOTE of a known-operator
+and not a primitive-procedure, or its primitive-procedure-name is not
+compiler:primitive-with-no-open-coding, LOOKUP with an a bound variable
+in a LETREC expression, LAMBDA.
+In a case where the operator is a QUOTE to an unknown operator and it is a
+primitive-procedure the CALL is rewriten with a CALL to %primitive-apply.
+In a CALL to a LAMBDA it gets rid of #!OPTIONAL and #!REST.
+
+Operators Introduced:
+---------------------
+%internal-apply used to replace CALLs to unknown operators.
+
+%primitive-apply used to replace CALLs to unknown primitive-procedures
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+none
+
+Guarantees on Output:
+---------------------
+ After this pass, CALLs only have the following kinds of operators:
+LAMBDA expressions, LOOKUP expressions where the variable is bound in
+a LETREC expression, or known operators, including %internal-apply and
+%primitive-apply.
--- /dev/null
+Description of assconv.scm
+
+Purpose:
+--------
+Eliminates all occurrences of SET!. In most cases a variable which is
+side-effected is replaced with a cell (%make-cell) and references to
+it are replaced by calls to %cell-ref or %cell-set!, although in
+certain other cases the variable may be bound by the use of a LETREC
+and/or LET instead. In some cases the value of a SET! is replaced by
+%unspecific. If the SET! provides an initial value for a variable,
+assconv may introduce the %unassigned cookie.
+
+Operators Introduced:
+---------------------
+%make-cell for local assigned variables
+%cell-ref for read references to local assigned variables
+%cell-set! for write references to local assigned variables
+%unspecific for the value returned by a SET! in some cases
+%unassigned for the initial value of a variable
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, LETREC, OR, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+------------------------
+ LETREC
+
+Magic Cookies handled specially:
+-------------------------------
+ none
+
+Guarantees on Output:
+---------------------
+No occurrences of SET!
+
+
--- /dev/null
+Description of cleanup.scm
+
+Purpose:
+--------
+
+CLEANUP is a general optimization phase, called several times. It
+primarly optimizes LETs and pseudo LETs (CALLs with LAMBDAs as their
+operators). This is a restricted form of static beta-substitution.
+
+1. It eliminates unused bound variables and substitutes bound
+variables by their values if the expressions for the values are
+sufficiently simple. Currently only the following value expressions
+can be substituted:
+ a) LOOKUP forms.
+ b) QUOTE forms.
+ c) CALLs to a simple magic cookie procedure (currently
+ %VECTOR-INDEX, %STACK-CLOSURE-REF and %HEAP-CLOSURE-REF) in
+ which all of the operands trivial (QUOTE or LOOKUP forms, or
+ calls to trivial operators (%VECTOR-INDEX) with quoted operands)
+ and there is at most one LOOKUP argument.
+The substitution is, of course, careful to avoid name capture.
+
+2. CALL to a LAMBDA is not quite identical to a LET, because there is
+a continuation to be considered. If the continuation to the CALL is
+%MAKE-STACK-CLOSURE it is handled very specially (see code for
+details).
+
+3. There is special handling for calls to explicit heap closures (i.e.
+expressions of the form
+ (CALL %INTERNAL-APPLY ...
+ (CALL %MAKE-HEAP-CLOSURE ... (LAMBDA (...) body))
+ ...)
+This can be converted to the simpler form
+ (CALL (LAMBDA (...') body'))
+if the body has no self-references.
+
+4. There is special handling for calls to explicit trivial closures,
+similar to that for explicit heap closures. This, too, replaces the
+closure with a LAMBDA expression.
+
+Operators Introduced:
+---------------------
+none
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+--------------------------------
+%HEAP-CLOSURE-REF for optimization 3 and as part of the restriction on
+ optimization 1.
+%VECTOR-INDEX and %STACK-CLOSURE-REF as part of the restriction on
+ optimization 1.
+%INTERNAL-APPLY for optimizations 3 and 4.
+%MAKE-HEAP-CLOSURE for optimization 3.
+%MAKE-TRIVIAL-CLOSURE for optimization 4.
+%MAKE-STACK-CLOSURE for optimization 2.
+
+Guarantees on Output:
+---------------------
+ No unused bindings.
--- /dev/null
+Description of closconv.scm
+
+Purpose:
+--------
+CLOSCONV is the closure converter. It rewrites instances of lambda
+expressions with free variables into calls to the pseudo-primitives
+%make-closure (and %make-trivial-closure). References to free
+variables of closures are rewritten as calls using the
+pseudo-primitive %closure-ref (and %vector-index).
+In a LETREC for closed-over env every ordinary-ref of a non-closed-over
+env, is changed into a CALL to %make-trivial-closure.
+Every free-ref (closed over) is replaced with %closure-ref and
+%vector-index. Also if the free ref variable is in the closed-over-names list
+produced by a call to the same procedure that rewrites lambda
+then %heap-closure-set is called.
+
+CLOSCONV, like LAMLIFT, is called twice, before and after CPS conversion.
+Before CPS conversion, it uses %make-heap-closure and %heap-closure-ref
+for %make-closure and %closure-ref. After CPS conversion, it uses
+%make-stack-closure and %stack-closure-ref instead.
+
+ After LAMLIFT and CLOSCONV, the only free variables in lambda
+expressions are those bound to static bindings (always available, e.g.
+from the program counter).
+
+Operators Introduced:
+---------------------
+%make-closure replaces free variables in LAMBDA and LETREC
+%make-heap-closure
+%make-trivial-closure constructs an externally callable procedure object
+(all free variables) are accessible through the variable caching mechanism
+.A LOOKUP is permitted only in a LETREC at the top level of a
+program. It is used to export one of the mutually recursive
+procedures introduced by the LETREC to the external environment.
+%make-stack-closure This appears *only* as the continuation of some
+KMP-Scheme CALL. If a lambda-expression is supplied, it pushes the
+values on the stack (creating a stack closure of the format specified) and
+loads the return address specified by the lambda-expression
+into the return address location (register or stack
+location). If no lambda expression is provided, simply
+pushes the values.
+
+%closure-ref replaces references to free variables.
+%stack-closure-ref
+%heap-closure-ref
+
+%vector-index used for referencing variables in closures and stack frames
+Returns the index of NAME within the vector.
+
+%heap-closure-set! used for closed-over-names in LETREC
+
+%fetch-stack-closure returns a pointer to the current top of
+ stack, which contains values (or cells for values) of the
+ variables named in VECTOR.
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+ none
+
+Guarantees on Output:
+---------------------
+ No non-local variable references.
+ After LAMLIFT and CLOSCONV, the only free variables in lambda
+expressions are those bound to static bindings (always available, e.g.
+from the program counter).
+
--- /dev/null
+Description of compat.scm
+
+Purpose:
+--------
+COMPAT is a compatibility rewrite stage. It makes unknown calls and
+exported procedures (i.e. closures) pass and accept parameters on the
+stack, following the current system's standard calling convention.
+It also rewrites calls to some pseudo-primitives into calls to
+existing primitives and free variables.
+(in other words it devides the parameters into ones that are in registers
+and ones that have to go on the stack and rewrites them)
+
+In general %fetch-continuation is used for the TOP-LEVEL cont.
+
+%fetch-stack-closure is used for LAMBDA for a continuation that is for
+variables on stack
+for variables on stack in LAMBDA a new env maps them to %stach-closure-ref
+and %vector-index.
+
+In CALL when the operator is not a pair or it is a quote
+when there are too many operands to put in registers they are
+put on the stack. The continuaition is changed into %make-stack-closure
+the stack operands are referenced with either LOOKUP or %stack-closure-ref
+If the operator is rewriten then the handler replaces the CALL,
+It can also get an out of line handler.
+
+kinds of (rewriten) calls which have extra arguments like arity or cache
+(therefore get a handler when CALLed)
+%invoke-operator-cache
+%invoke-remote-cache
+%internal-apply
+%invoke-continuation
+
+rewriten operators
+%vector-index
+%variable-cache-ref {checks that the cont of the call is to a QUOTE or a
+ LOOKUP otherwise error. using %stack-closure-ref}
+ %continue is used to represent the continuation using
+ %invoke-continuation for continuation that are a QUOTE
+ uses %variable-read-cache for cell-name
+ uses %variable-cell-ref for value-name
+ uses %reference-trap? and %hook-variable-cell-ref
+%safe-variable-cahce-ref is like %variable-cache-ref except in the end
+ it calls %unassigned? instead of %hook-variable-cell-ref and then
+ %hook-safe-variable-cell-ref.
+%variable-cache-set! the same as above uses %variable-write-cache
+ for cell-name. old-value-name uses %variable-cell-ref
+ uses %variable-cell-set! and %hook-variable-cell-set! instead of
+ %continuation and %hook...
+%primitive-apply uses %primitive-apply/compatible also uses (not introduces)
+ %make-stack-closure and %stack-closure-ref (for a CALL)
+
+%invoke-remote-cache and %primitive-apply/compatible are introduced
+
+Operators removed:
+------------------
+
+%*lookup is replaced by a call to the primitive LEXICAL-REFERENCE
+
+%*set! is replaced by a call to the primitive LEXICAL-ASSIGNMENT
+
+%*unassigned? is replaced by a call to the primitive LEXICAL-UNASSIGNED?
+
+%*define is replaced by a call to the primitive LOCAL-ASSIGNMENT
+
+%*define* is replaced by a call to the global procedure DEFINE-MULTIPLE
+
+%*make-enviornment is replaced by a call to the global procedure
+ *MAKE-ENVIRONMENT
+
+%*variable-cache-ref is replaced by a lot of hairy code
+
+%*variable-cache-set! is replaced by a lot of hairy code
+
+%safe-variable-cache-ref is replaced by a lot of hairy code
+
+%copy-program is replaced by a call to a global procedure COPY-PROGRAM
+
+%execute is replaced by a call to a primitive procedure SCODE-EVAL
+
+%primitive-apply is replaced by %PRIMITIVE-APPLY/COMPATIBLE
+
+
+Operators Introduced:
+---------------------
+
+%variable-read-cache as part of rewriting %variable-cache-ref and
+ %safe-variable-cache-ref
+
+%variable-write-cache as part of rewriting %variable-cache-set!
+
+%variable-cell-ref as part of rewriting %safe-cache-ref and
+ %safe-variable-cache-ref
+
+%variable-cell-set! as part of rewriting %variable-cache-set!
+
+%hook-variable-cell-ref as part of rewriting %variable-cache-ref
+
+%hook-safe-variable-cell-ref as part of rewriting %safe-variable-cache-ref
+
+%hook-variable-cell-set! as part of rewriting %variable-cache-set!
+
+%reference-trap? as part of rewriting %variable-cache-ref,
+ %safe-variable-cache-ref, and %variable-cache-set!
+
+%make-stack-closure (also by closeconv.scm) with #F
+
+%primitive-apply/compatible
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+
+Guarantees on Output:
+---------------------
+ none
+
+
+
+
+
+
+
--- /dev/null
+Description of copier.scm
--- /dev/null
+Description of cpsconv.scm
+
+Description of applicat.scm
+
+Purpose:
+--------
+CPSCONV is the CPS converter. It makes most implicit continuations
+explicit, rewriting calls to create new ones, or pass old ones, and
+returns as calls to the continuation. The RTL generator can handle
+some simple expressions (including out-of-line arithmetic), so parts
+of the program (those sufficiently "simple") are not CPS converted.
+CPSCONV also chooses the order of argument evaluation.
+ After this pass, the only implicit continuation creation is of the
+continuations of special out-of-line handlers that can preserve the
+relevant registers.
+ Important: LAMLIFT and CLOSCONV are run again after CPSCONV. This
+has the effect of making all state preserved around non-simple
+subproblem calls (except those introduced by LATEREW) explicit.
+State is preserved in stack closures that are created and manipulated
+by means of pseudo-primitives.
+
+
+
+Operators Introduced:
+---------------------
+%fetch-continuation Grab return address, for use in top-level expressions since they (unlike procedures) do not receive a continuation.
+%unspecific represents an ignorable value.
+%invoke-continuation introduced for named continuations.
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+none
+
+Guarantees on Output:
+---------------------
+ After this pass, the only implicit continuation creation is of the
+continuations of special out-of-line handlers that can preserve the
+relevant registers.
\ No newline at end of file
--- /dev/null
+Description of dataflow.scm
--- /dev/null
+Description of dbgstr.scm
--- /dev/null
+Description of debug.scm
--- /dev/null
+Description of earlyrew.scm
+
+Purpose:
+--------
+
+EARLYREW is a primitive rewrite stage that occurs before CPS
+conversion. Branches introduced here are visible at the CPS
+conversion stage, and may cause new procedures to be created.
+
+Rewrites unary operations in terms of binary operations. For binary
+operations it checks for the type and choses whether to use generic,
+fixnum, or machine operator (using %machine-fixnum? %small-fixnum?)
+or it does an optimization.
+
+It also rewrites STRING-ALLOCATE, FLOATING-VECTOR-CONS and
+VECTOR-CONS. (It is done this way because of the current rtl
+generator.)
+
+
+Operators Introduced:
+---------------------
+%*
+%+
+%-
+%/
+%<
+%=
+%>
+%floating-vector-cons
+%machine-fixnum?
+%quotient
+%remainder
+%small-fixnum
+%string-allocate
+%vector-allocate
+%vector-cons
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+
+The procedure DEFINE-REWRITE/EARLY is used to specify rewriting
+procedures. At the current time, the following operations are
+rewritten:
+ &*, &+, &-, &/, &<, &=, &>, -1+, 1+, FLOATING-VECTOR-CONS, FLONUM-ABS,
+ FLONUM-NEGATE, FLONUM-NEGATIVE?, FLONUM-POSITIVE?, FLONUM-ZERO?,
+ GENERAL-CAR-CDR, MINUS-ONE-PLUS-FIXNUM, NEGATIVE-FIXNUM?, NEGATIVE?,
+ ONE-PLUS-FIXNUM, POSITIVE-FIXNUM?, POSITIVE?, QUOTIENT, REMAINDER,
+ STRING-ALLOCATE, VECTOR-CONS, ZERO-FIXNUM?, ZERO?
+
+
+Guarantees on Output:
+---------------------
+ none
+
--- /dev/null
+Description of envconv.scm
+
+PURPOSE:
+--------
+
+ENVCONV takes care of first-class environments, incremental
+(top-level) definition and variable references to first-class
+environments. It rewrites implicit environment operations into
+explicit operations, and references to variables in first-class
+environments as procedure calls to environment or variable cache
+operations.
+
+ENVCONV initiates recursive calls to the compiler when:
+1) compiling by procedure and a top-level LAMBDA expression must be
+ compiled.
+2) compling the body of an IN-PACKAGE where the environment expression
+ isn't '(THE-ENVIRONMENT)
+3) compiling an expression which is not top-level, requires static
+ variable caches, and the evaluation environment is reified (i.e.
+ there are first class references to the environment).
+
+References to variables bound in reified frames are considered
+captured by the closest reified frame to the frame in which the
+reference occurs. References to such captured variables may be
+implemented using calls to "magic cookie functions" or variable
+caches. The global variable ENVCONV/OPTIMIZATION-LEVEL determines
+which of these frames use variable cache cells:
+ A. If 'LOW, none (always use the magic cookie fuctions).
+ B. If 'MEDIUM (the default setting), only those whose context is
+ TOP-LEVEL.
+ C. If 'HIGH, all (never use the magic cookie functions).
+
+Eliminates all occurrences of:
+-----------------------------
+
+THE-ENVIRONMENT is, usually, replaced by a LOOKUP to a newly created
+ variable that will hold the value of the reified environment at
+ runtime. Notice that (THE-ENVIRONMENT) is handled specially if it
+ occurs in an IN-PACKAGE or ACCESS form.
+
+ACCESS is replaced by either LOOKUP (when the environment expression
+ is '(THE-ENVIRONMENT)) or %*lookup.
+
+DEFINE is replaced by %*define for top-level definitions or by SET!.
+
+IN-PACKAGE is replaced by a combination of %execute, %copy-program and
+ %fetch-environment.
+
+Operators Introduced:
+---------------------
+
+%COPY-PROGRAM around code blocks that must be copied before use (for
+ example, the body of an IN-PACKAGE that can be executed more than
+ once)
+%*DEFINE in lieu of DEFINE at the top level
+%EXECUTE to invoke recursively compiled expressions
+%FETCH-ENVIRONMENT around compiled code blocks that require access to
+ the environment in which they were linked
+%INVOKE-OPERATOR-CACHE replaces the operator of a CALL when the
+ operator had been LOOKUP of a variable that has a cache cell
+%INVOKE-REMOTE-CACHE replaces the operator of a CALL when the operator
+ had been ACCESS of a variable in an environment that has a cache
+ cell
+%*LOOKUP in lieu of ACCESS forms, and LOOKUP to certain variables when
+ cache cells aren't in use
+%*MAKE-ENVIRONMENT around bodies that require a reified environment
+%MAKE-OPERATOR-VARIABLE-CACHE,
+%MAKE-READ-VARIABLE-CACHE,
+%MAKE-REMOTE-OPERATOR-VARIABLE-CACHE and
+%MAKE-WRITE-VARIABLE-CACHE to create cache cells around code bodies
+ that require them
+%SAFE-VARIABLE-CACHE-REF as part of the rewrite for SET! and
+ UNASSIGNED? of a variable that has a cache cell
+%*SET! in lieu of SET! and DEFINE when cache cells are not being used
+%*UNASSIGNED? in lieu of UNASSIGNED? when cache cells are not used
+%UNASSIGNED? in lieu of UNASSIGNED? when cache cells are used
+%VARIABLE-CACHE-REF replaces LOOKUP of a variable that has a cache
+ cell
+%VARIABLE-CACHE-SET! as part of the rewrite of SET! of a variable that
+ has a cache cell
+
+Restrictions on Input:
+----------------------
+
+Special forms excluded:
+ LETREC
+
+Special forms introduced:
+------------------------
+
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+
+ %system-global-environment
+
+Guarantees on Output:
+---------------------
+
+1. There are no implicit manipulations of environments.
+2. LAMBDAs and LETs create non-reified environments.
+3. There are no occurrences of THE-ENVIRONMENT, ACCESS, IN-PACKAGE or
+ DEFINE.
+
+
+
+
+
+
+
+
+
+
+
+
--- /dev/null
+Description of expand.scm
+Purpose:
+--------
+Eliminates all occurrences of the special forms DELAY (introducing
+%make-promise), OR (by expansion), and UNASSIGNED? (introducing
+%unassigned?).
+
+Eliminates #!AUX bindings from lambda expressions by replacing them
+with a LET binding inside the LAMBDA, giving them an initial value of
+%unassigned. Inside of this LET it puts SET! initializations, sorted
+to place simple values (QUOTE or LAMBDA) first. This helps the single
+assignment analysis in assconv (the one that introduces LETREC).
+
+Sequential DEFINEs are turned into a MULTI-DEFINE, introducing
+%*define* and %vector.
+
+Operators Introduced:
+---------------------
+%*define* for DEFINE_MULTIPLE
+%unassigned? for replacing UNASSIGNED?
+%unassigned for the initial value of a variable
+%vector for a vector of the values of the multiple defines
+%make-promise for DELAY
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, IN-PACKAGE, LETREC, THE-ENVIRONMENT
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+--------------------------------
+ %*define: multiple %*define in the same body are replaced by a
+ single %*define*
+
+Guarantees on Output:
+---------------------
+No occurrences of DELAY, OR, UNASSIGNED? or #!AUX bindings in lambda
+expressions.
--- /dev/null
+Description of fakeprim.scm
--- /dev/null
+Description of graph.scm
--- /dev/null
+Description of indexify.scm
+
+Purpose:
+--------
+INDEXIFY replaces calls to the pseudo-primitive %vector-index with
+result of calling vector-index at compile time.
+
+Operators Introduced:
+---------------------
+none
+
+Operators removed:
+------------------
+%vector-index is replaced by a constant integer
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+none
+
+Guarantees on Output:
+---------------------
+ No references to %vector-index.
+
+
+
--- /dev/null
+Description of inlate.scm
+
+Purpose:
+--------
+INLATE translates scode into KMP Scheme.
+
+Operators Introduced:
+---------------------
+%unassigned for explicit references to the unassigned-reference-trap
+object.
+
+Restrictions on Input:
+----------------------
+none
+
+Special forms introduced:
+-------------------------
+ACCESS BEGIN CALL DECLARE DEFINE DELAY IF IN-PACKAGE LAMBDA LET LOOKUP
+OR QUOTE SET! THE-ENVIRONMENT UNASSIGNED?
+
+Magic Cookies handled specially:
+-------------------------------
+none
+
+Guarantees on Output:
+---------------------
+1. Code is now in KMP Scheme, with continuation parameters added to
+ LAMBDA expressions but no self-reference or environment parameters.
+2. All continuation slots in CALLs are set to #F.
+3. The output does not include the LETREC special form.
+4. The only magic cookie in the output is %unassigned.
+
--- /dev/null
+This file describes the overall syntax of kmp-scheme.
+
+see ~gjr/work/liar94/text/forms.txt:
+
+;;; -*- Text -*-
+
+;; Output of input stage (except for LETREC).
+
+<expression> =
+ (QUOTE <object>) ; constant object reference
+| (LOOKUP <name>) ; variable reference
+| (LAMBDA <lambda-list> <expression>) ; procedural abstraction
+| (LET (<binding>*) <expression>) ; simple variable binding
+| (DECLARE <declaration>*) ; ??
+| (CALL <expression> <expression>+) ; procedure application
+| (BEGIN <expression>*) ; sequential execution
+| (IF <expression> <expression> <expression>)
+ ; conditional execution
+;; The following is introduced by "assconv.scm", it need not be handled before
+| (LETREC (<binding>*) <expression>) ; mutually recursive bindings:
+ ; only lambda-expressions allowed.
+;; The following need not be handled after "assconv.scm"
+| (SET! <name> <expression>) ; variable assignment
+;; The following need not be handled after "expand.scm"
+| (OR <expression> <expression> ; conditional execution
+| (DELAY <expression>) ; promise construction
+| (UNASSIGNED? <name>) ; variable initialization test
+;; The following need not be handled after "envconv.scm"
+| (ACCESS <name> <expression>) ; variable reference in computed env.
+| (DEFINE <name> <expression>) ; variable definition
+| (THE-ENVIRONMENT) ; environment reification
+| (IN-PACKAGE <expression> <expression>)
+ ; evaluation in computed environments
+
+<binding> = (<name> <expression>)
+ ; LET allows only simple expressions
+ ; LETREC allows only LAMBDA expressions
+
+<lambda-list> = (<name>* <optionals> <rest> <aux>)
+
+<optionals> = <empty>
+ | #!optional <name>+
+
+<rest> = <empty>
+ | #!rest <name>
+
+<aux> = <empty>
+ | #!aux <name>+
+
+<aux> is eliminated in expand.scm. It is not handled afterwards.
+
+CALL expressions have at least two subexpressions:
+- operator
+- continuation ('#f until cps)
+
+<thing>* means 0 or more <thing>
+<thing>+ means 1 or more <thing>
--- /dev/null
+Description of lamlift.scm
+
+Purpose:
+--------
+
+To reduce the number of closures in a program.
+
+Lambda lifting is a code-motion transformation whereby LAMBDA
+expressions are moved to a higher frame. Bindings from frames below
+the new location of the lifted LAMBDA expression must be passed as
+extra parameters.
+
+A lifted LAMBDA represents a more eager but possibly less frequent
+closing over its remaining free variables. This version lifts 'all
+the way', so that there are no remaining free variables, so the cost
+of closing is reduced to nil at the expense of passing possibly many
+more arguments. The only remaining closures are absoultely necessary.
+
+
+Operators Introduced:
+---------------------
+ none
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+ none
+
+Guarantees on Output:
+---------------------
+
+ . Procedures with no dynamic free variables (see definitions under
+ Algorithm notes) are lifted up into a static frame so that they
+ need not be considered for further closure-oriented
+ transformations.
+
+ . The current version guarrantees that if a non-closure procedure is
+ used in both operator and operand positions then that procedure
+ will be refered to via a named stub procedure in the operand
+ position and a lifted procedure in the operator position.
+
+ This unnecessary splitting of the procedure into two hides a
+ related bug in rtlgen where an operator/operand-shared lambda
+ appears is compiled as one of a PROCEDURE or a TRIVIAL-CLOSURE
+ whereas both are required. The right place to fix this bug is
+ either closconv, which should know about this nasty property of
+ %make-trivial-closure, or in rtlgen.
+
+
+Algorithm notes:
+----------------
+
+It is a subject of debate as to how far one should `lift' lambdas.
+This algorithm lifts `all the way', passing all dynamic free variables
+as parameters.
+
+Definitions:
+
+ . Environment frames are either STATIC or DYNAMIC. A STATIC frame
+ will have no reification at runtime, and all STATIC frames are
+ outside of DYNAMIC frames.
+
+ . "Dynamic free variables" are free variables of a LAMBDA expression
+ that have their binding in a DYNAMIC frame.
+
+There are two parts to the process: deciding where to place the lifted
+lambdas and hence which additional parameters to add, and then editing
+the program.
+
+
+Deciding for LAMBDAs
+
+A LAMBDA requires the following extra formals:
+
+ . Any references to dynamic free variables
+ . Any parameters required to call other procedures which have extra
+ parameters due being lifted.
+
+
+Program Editing
+
+A lambda is split into two lambdas: a body lambda, which takes all the
+extra parameters and contains the original lambda's body, and a stub,
+which has the original signature and calls the body lambda. All known
+call sites to the lambda are re-written to call the body-lambda, and
+we choose at this point to handle #!optional and #!rest parameters,
+allowing the body lambda to have a simple lambda-list. As the
+operator position references are rewritten, a stub is required only
+when there are operand position references to the lambda. The stub
+may be left either in the position of the original lambda or lifted so
+log as no extra parameters are required.
+
+
+Deciding for LETRECs
+
+A LETREC is more complicated because the names bound in the LETREC may
+be free in the bodies of the LAMBDAS bound to those names. (We have
+the usual restriction that the right hand side of each binding must be
+a LAMBDA expression.) The hard thing to decide is which of the LETREC
+bindings need to be passed as extra parameters.
+
+
+Algorithm:
+
+1. Create an model of the existing program environment structure,
+ telling the location of each binding frame, the variables bound,
+ the parent and children bindings frames.
+
+2. Identify all free variable references in each body, and mark each
+ as "dynamic" or "static" as well as "operator" or "operand".
+
+3. Create a directed graph where each node is a LAMBDA expression
+ bound in the LETREC, and each edge is a reference (operator or
+ operand) to a node, i.e. a LOOKUP of one of the LETREC bindings.
+ This is the REFERENCE GRAPH. The strongly connected components
+ of this graph identify which groups of LAMBDAs are constrained by
+ mutual references to remain together in a LETREC environment frame.
+
+4. Processing each component before any component that references it,
+ find the DRIFT FRAME, the highest frame that a component may be
+ lifted to without adding extra arguments. This frame is the
+ highest to which the stubs my be lifted. When processing other
+ components assume this component has been lifted to this frame
+ (which is why order is important).
+
+5. Create a CALL GRAPH: a directed graph where each node is a LAMBDA
+ expression bound in the LETREC, and each edge is a call (operator
+ position reference) to a node. The strongly connected components
+ of this graph identify which groups of LAMBDAs are contrained to
+ pass the same set of free variables. (Each call graph component is
+ a subset of some reference graph component.)
+
+6. For each call graph component, processing a component before any
+ which calls it, find the dynamic free variables for that component.
+ These are the extra formals for each member of the component.
+ . Operator references to components are not added because they
+ will be rewritten as calls to the lifted bodies.
+ . Operand references to components which have a static drift frame
+ are not included in the dynamic free references under the
+ assumbption that the stubs will be lifted to the static frame.
+
+7. Lift the LAMBDAs using these extra formals.
+
+8. Lift the stubs. Stubs which drift to static frames MUST be lifted.
+ Other stubs should be treated as in the simple LAMBDA case.
--- /dev/null
+Description of laterew.scm
+
+Purpose:
+--------
+LATEREW is a primitive rewrite stage that occurs after CPS conversion.
+Branches introduced here will not create new lambda expressions, and
+non-simple operators introduced here must be able to preserve the
+relevant state when called.
+
+
+
+Operators Introduced:
+---------------------
+%continue is used to repexent the continuation.
+%invoke-continuation if continuation is not a quote then it is CALLed
+%stack-closure-ref if an operator is a CALL to it then error of unexpected
+continuation.
+%+
+%-
+%*
+%=
+%<
+%>
+%quotient
+%remainder
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+%fixop used if the operands are fixnum
+%genop used if the operands are not numbers or fixnums.
+%test used to determine which test of fixnum from below to use.
+
+%small-fixnum?
+%machine-fixnum? uses to test if the operand is a fixnum then uses %fixop.
+
+
+Guarantees on Output:
+---------------------
+ operators are rewriten without creating new lambda expretions, and non simple
+operators must be able to preserve relevant state when called.
+
+
--- /dev/null
+Description of load.scm
--- /dev/null
+Description of midend.scm
--- /dev/null
+
+This file will contain an overview of the `middle end' of the
+compiler.
+
+See ~gjr/work/liar94/text/passes.txt
+
+It will also describe how a `generic' rewriting phase works.
+
+There is a file for each rewriting phase describing:
+
+ . The input language
+ . The ouput language
+ . How it works (e.g two pass, substitute mumble for mumble)
+ . Details of how it works, including any trick, use of assumptions etc.
\ No newline at end of file
--- /dev/null
+Description of rtlgen.scm
+
+Rtlgen converts a restrcited subset of KMP-Scheme into RTL. It is the
+largest phase of the compiler because does a job similar to a C
+compiler - it takes a language which few higher level features and
+translates it into a conventional intermediate language.
+
+
+Restrictions on Input Language:
+
+Expressions are either Static, meaning computed by the compiler or the
+system (e.g. the linker), or Dynamic, meaning computed by the program.
+Bindings are classified similarly according to the expression that
+calculates the value to which the name is bound.
+
+*Statements
+
+ . KMP-Scheme is syntactically split into two sublanguage. Each
+ expression is either a (stack-closure) continuation or an ordinary
+ value.
+
+ Continuation-`valued' identifiers are only bound by the
+ continuation formal of a LAMBDA. Continuation-`valued' expressions
+ are:
+
+ - (LOOKUP cont-name)
+ - (CALL '%make-stack-closure ...)
+ - '#F (used for binding a useless formal, and in the expression
+ sublanguage)
+
+ - (CALL '%stack-closure-ref .... ) of a slot allocated
+
+
+ . LAMBDA can appear in two contexts:
+
+ - As a Static expression, in which case it may have no free dynamic
+ bindings. This is compiled to the appropriate kind of compiled
+ code object.
+
+ - In the following Let-like context for binding a continuation:
+
+ (CALL (LAMBDA (continuation-variable)
+ ...)
+ continuation-expressiion)
+
+
+
+A GRAMMAR
+
+This grammar tries to capture the restrictions on the language.
+
+
+stmt = (CALL stmt-operator cont expr ...)
+ (IF expr stmt stmt)
+ (BEGIN expr|decl ... stmt)
+ (LET (binding*) stmt)
+ (LETREC (letrec-binding*) stmt)
+ (CALL (LAMBDA (continuation-variable) stmt)
+ cont)
+
+ none of QUOTE LOOKUP LAMBDA are statements
+
+stmt-operator = (LOOKUP static-name)
+ (QUOTE stmt-cookie)
+ (QUOTE primitive-procedure)
+
+stmt-cookie = %invoke-continuation
+ %internal-apply
+ %invoke-operator-cache
+ %invoke-remote-cache
+ %primitive-apply/compatible
+
+expr = (QUOTE object)
+ (LOOKUP name) ; not a continuation variable
+ lambda-expr
+ (CALL expr-operator '#F expr ...)
+ (CALL '%stack-closure-ref ... 'name) ; not a continuation variable
+ (BEGIN expr|decl ... expr)
+ (IF expr expr expr)
+ (LET (binding*) expr)
+ (LETREC (letrec-binding*) expr)
+
+expr-operator = (QUOTE expr-cookie)
+ (QUOTE primitive-procedure)
+
+expr-cookie = ...
+ does NOT include %stack-closure-ref
+
+lambda-expr = (LAMBDA lambda-list stmt)
+
+binding = (name expr)
+letrec-binding = (name lambda-expr)
+
+decl = (DECLARE declaration*)
+
+cont = (LOOKUP name) ; name is continuation variable
+ (CALL '%stack-closure-ref ... 'name) ; name is continuation variable
+ (CALL '%make-stack-closure
+ '#F
+ rcont
+ '#(names ...)
+ expr|scont
+ expr ...)
+
+rcont = (LOOKUP name) ; name is continuation variable
+ (CALL '%stack-closure-ref ... 'name) ; name is continuation variable
+ '#F ; for calling primitives
+
+scont = (LOOKUP name) ; name is continuation variable
+ (CALL '%stack-closure-ref ... 'name) ; name is continuation variable
+
+
+Notes:
+
+ . %make-stack-closure is forbidden as an rcont because the two
+ frames can be merged
+ . %make-stack-closure is forbidden as an scont because it can be
+ rewritten using (CALL (LAMBDA (cont) ...) ...)
+ .
+
+
+(QUOTE object)
+(LOOKUP name)
+(LAMBDA lambda-list expression)
+(LET (binding*) expression)
+(DECLARE declaration*)
+(CALL expression expression+)
+(BEGIN expression*)
+(IF expression expression expression)
+(LETREC (binding*) expression)
+
+
+
+
+
+Operators ignored:
+------------------
+
+%make-operator-variable-cache
+
+%make-remote-operator-variable-cache
+
+%make-read-variable-cache
+
+%make-write-variable-cache
+
--- /dev/null
+Description of simplify.scm
+
+Purpose:
+--------
+
+SIMPLIFY is a general optimization phase, called several times. It is
+the dual of CLEANUP and works in conjunction with it. It examines
+variable bindings and rewrites CALLs with LOOKUP operators into CALLs
+with LAMBDA operators which CLEANUP will then reduce further. (It does
+that if it is a lambda without ordinary refs and either only one
+operator ref or the the value is a call to a lookup. Also if the
+length of the ordinary and the length of the operator ref equals 1 and
+the binding is simple and side effect free or insensitive). If the
+lambda expression is simple enough then it removes the binding and
+removes the lookup and just assignes the values straight to the
+variable and leaves the let with no variables.
+
+1st-half of beta substitution replace variable operators with lambda expressions
+
+Operators Introduced:
+---------------------
+none
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+none
+
+Guarantees on Output:
+---------------------
+ none
+
--- /dev/null
+Description of split.scm
--- /dev/null
+Description of stackopt.scm
+
+Purpose:
+--------
+STACKOPT attempts to reduce stack thrashing by examining temporaly
+contiguous stack frames and attempting to make their layout as similar
+as possible so that as few elements as possible need to be moved from
+one stack slot to another.
+
+There is more indepth documentation in stackopt.scm
+
+[
+In a CALL if the continuation matches a %make-stack-closure with a non
+lambda expression then it returns as the continuation a CALL using
+%make-stack-lambda. otherwise it goes to the general case
+ (if the call-fram-vector
+and the cont-fram-vector are the same the the case should be handled
+specialy becasue like in the case of non-lambda expression the stack
+has variables that cannot be moved. ) it uses %make-stack-closure
+and %fetch-stack-closure and makes the state false so that it can
+do the next step.
+(when state is false) The common names that are in a frame and its
+descendents are maped to a fixed stack offset. so that to minnimize moving
+them from one memory location to the other and having to load them
+and save them many times. other variables are assigned to free places
+]
+Operators Introduced:
+---------------------
+%make-stack-closure to be used in the cont which matches a pattern
+ containing it.
+
+%fetch-stack-closure to be used in the cont of a lambda expression
+
+Restrictions on Input:
+----------------------
+Special forms excluded:
+ ACCESS, DEFINE, DELAY, IN-PACKAGE, OR, SET!, THE-ENVIRONMENT
+ UNASSIGNED?
+
+Special forms introduced:
+-------------------------
+ none
+
+Magic Cookies handled specially:
+-------------------------------
+%make-stack-closure contained in fixed locations that cannot be changed
+ at a given point in the computation.
+
+%fetch-stack-closure is used to see whether the cont matches a pattern
+ containing it in order to get the proper layout.
+
+Guarantees on Output:
+---------------------
+ none
+
--- /dev/null
+Description of staticfy.scm
--- /dev/null
+Description of synutl.scm
--- /dev/null
+Description of triveval.scm
--- /dev/null
+Description of utils.scm
--- /dev/null
+Description of widen.scm
projects / mit-scheme.git / commitdiff