[LispM-Hackers] Function calling

[James A. Crippen]

The current macroops pending implementation are the CALL-* series of
mainops that implement function calling (SSDN ch 11).  I'm thinking
that the function calling instructions should be implemented
concurrently with the return instructions, since they all operate on
similar structures.

The first things that need to be set up for any function call are

 * Find the function
 * Find the new argument pointer
 * Find the new call-info word
 * Find the number of supplied arguments

then the data type of the function can be dispatched on.  When the
dispatch occurs the SSDN (11.7.2) states that the function is
guaranteed to be in MD, the new argument pointer in M-G, the new
call-info word in M-F, and the number of supplied arguments in M-H.
The MD is a lone register, the others are locations in M-memory.

We need to implement M-memory and A-memory.  The way I envision these
being implemented is as a single array instance with two sets of
accessors, one set that operates on the M-memory subarray and one set
that operates on the entire A-memory array.  To explain (SSDN 1.1.2),
the A-memory is a 1K (2^10) block of 32-bit words, and the M-memory a
block of 64 32-bit words that is an exact duplicate of the first 64 words
of A-memory.  Since these two must be kept synchronized I figure that
implementing them as the same data structure would avoid the necessity
of copying a lot of data back and forth with each emulation cycle.

A few other things need to be implemented on the CPU side as well as
A- and M-memories.  We need the PDL, PDL pointer, and PDL index.  The
PDL is 1K by 32-bit words.  These shouldn't be difficult.  I may
implement them in the next day or so.

The two components which trouble me are the MD and VMA registers.  The
MD register "can be thought of as the processor's window.  When data
is read from outside the processor it comes into the MD register.
When data is to be written outside the processor it is first placed
into the MD register."  The MD holds the data which the processor is
to read or write and the VMA register holds the location where the
data is to be read from or written to.  Based on the name of the VMA
register I assume that the locations in the VMA register are virtual
memory addresses, ie addresses similar to those in a DTP-LOCATIVE q.
I'm not really sure if these are actually used by macrocode
instructions explicitly or whether we can completely dispense with
them.  I've not seen anything in particular so far that clearly
answers this question one way or the other.

Another thing that is still troubling me is more related to the return
instructions, the Indicators.  In the Explorer I processor notes the
only two fields listed for the Explorer I processor indicators were
one for 'ATOMP' and 'NILP' (par abus de langage).  I have no idea what
the indicators can indicate in the Explorer II, and would like to know
where to go looking for such information.  I have a feeling that if I
spent a while digging through OS and compiler sources I might find the
definitions of some symbols that represent values in the indicators,
but I'm not totally sure about that and have no idea what to look
for.  Implementation-wise I figure that collecting the indicators into
a single class and providing accessors and mutators for each separate
slot would be most efficient.  The slots should be e3u8 or the like
since they're most likely going to be truth values and bytes are cheap
to test on most architectures.

If anyone has any clarifications on what I've posted above, don't
hesitate to follow up.  I'm not writing anything yet because I'm still
trying to get a handle on what general structure is needed (so I don't
end up reimplementing something N times).  I'll post more info soon.

'james

-- 
James A. Crippen <james@unlambda.com> ,-./-.  Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us   |  |/  | USA, 61.2069 N, 149.766 W,
Y = \f.(\x.f(xx)) (\x.f(xx))         |  |\  | Earth, Sol System,
Y(F) = F(Y(F))                        \_,-_/  Milky Way.