[LispM-Hackers] First Function

[Paul Fuqua]

    Date: Fri, 1 Mar 2002 22:28:28 -0800
    From: "Dave Richards" <dave@synergy.org>
    
    (a) INSN 0 is a problem.  SET-NIL (this is not a disassembler bug, I
    double-checked it against SSDN2) assigns NIL to the desination.  Why can
    this INSN assign to the PDL that far back?

I still don't have my Explorer put back together (but it's getting
closer) so I can't get a true disassembly yet, but I know that the
initial function is (usually?) SYS:LISP-TOP-LEVEL (in
sys:kernel;lisp-reinitialize.lisp), which looks like this:

;Come here when machine starts.  Provides a base frame.
(DEFUN LISP-TOP-LEVEL ()
   (LISP-REINITIALIZE NIL)                      ;(Re)Initialize critical variables and things
   (TERPRI (OR TV:INITIAL-LISP-LISTENER *TERMINAL-IO*))
   ;;  LISP-TOP-LEVEL1 supposedly never returns, but loop anyway in case
   ;;  someone forces it to return with the error-handler.
   (LOOP DOING
         (IF (FBOUNDP 'PROCESS-TOP-LEVEL)
             (PROCESS-TOP-LEVEL)
             (LISP-TOP-LEVEL1 (OR TV:INITIAL-LISP-LISTENER *TERMINAL-IO*)))))

The first thing it does is call LISP-REINITIALIZE with an arg of NIL, so
I think this SET-NIL variant may be magic for PUSH-N-NILS, which I know
we have somewhere to build stack frames.
    
    It may make more sense to turn the location count into a halfword
    counter.  This would allow branch displacement arithmetic to work
    correctly as well as allowing readMacroInstruction to take one
    (instead of two) location values.  I wonder how Explorer stored
    this?

The hardware location counter was a halfword pointer.  The fetch
hardware read a word at a time, refilling as needed.
    
    (d) The disassembler didn't have this guy, but SSDN2 says it's FBOUNDP,
    which makes sense because FEP|7 holds a symbol.

Also makes sense given the code quoted above.
    
    (g) EVCPs (based on Sect 11) are invisible pointers.

External Value Cell Pointers, so called because they originated as a
means for dynamic closures to point back to their closed-over-symbol
values.  Since they're a handy forwarding pointer, a function calling a
symbol would carry an EVCP to the symbol's value cell (not directly to
the function, because we need to catch redefinitions, but I'm not sure
why we didn't just point to the symbol;  probably for a faster calling
sequence).
    
    Is there any place where the registers of the processor are defined?  I
    don't mean the micro-registers, I mean the macro ones.  We know that
    registers must exist for the stack pointer, location counter, current
    function.  There must also be some environment registers, etc.

There aren't that many, and most of them are really just microcode
memory locations (though I think Explorer 2 put some of them in
hardware for speed).  I don't know if there's a master list like you're
looking for, but there are lists in the stack-group description, the
function-calling description, and elsewhere.

                              pf