[LispM-Hackers] Funcall notes

[Paul Fuqua]

    Date: 18 Oct 2001 13:34:26 -0800
    From: james@unlambda.com (James A. Crippen)
    
    What is it that pushes its own address?  And why do things return
    here?  Where's 'here'?

"Here" means to this step in the process, ie, about to calculate the LC
offset.  "Pushes its own address" is a reference to the type of dispatch
microinstruction, basically meaning it's (mostly) a call instead of a
branch.

Lots of things were functional objects on the Explorer.  DTP-FUNCTION,
obviously.  DTP-SYMBOL would look fetch the function cell of the symbol
and come back with a DTP-FUNCTION.  DTP-INSTANCE would do a method-table
lookup and come back.  DTP-ARRAY would turn into an AREF and *not* come
back (allowed for old historical reasons).  DTP-LIST would fake a call
to SYS:APPLY-LAMBDA to jump into the interpreter, and come back with
that DTP-FUNCTION (I think).  DTP-LEXICAL-CLOSURE and DTP-CLOSURE would
pull the function out of the closure and come back.  And so on;  see
"Calling Anything Else."

In other words, the simple common case, DTP-FUNCTION, falls through to
the next step, while most other things jump out of the common path to go
find a DTP-FUNCTION.

    Another question is where the location-counter offset goes when it's
    calculated from the previous function.

Into the call frame, one of the five state words, where it can be used
to restart the LC in the caller when returning.
    
    Do we need to check for PDL-buffer overflow or does PDL-buffer in this
    case refer to the PDL-cache that is in the processor?  If indeed we
    need to grow the PDL-buffer then what do we do?

It's just the cache.  I think overflowing in that sense just meant that
some had to be written out to make space for more.  If there was an
actual overflow of the PDL array itself, it would cause a trap, where
the debugger would offer an option to extend the array.  Either way,
it's essentially transparent to the CALL instruction (aside from the
check) as either the situation gets cleaned up or the call is aborted.
    
    What happens if we have too many arguments?

We trap.  Calls always know how many arguments are supplied, functions
always know how many they want, and if there's a mismatch, we trap and
end up in the debugger (where we might do anything from aborting to
adding args to dropping args to modifying args).

(And while I forget the exact mechanism, trapping involves switching to
the debugger stack group, saving the micro-pc so we can look it up in a
list that gives us an atom that indicates the type of condition to
signal.)

                              pf