[LispM-Hackers] First Function

Dave Richards dave@synergy.org
Sun, 3 Mar 2002 08:58:03 -0800


We can determine that first target function easily enough:

	1. The EVCP should be an address within a DTP-SYMBOL-HEADER structure.
	2. Subtract/add an the difference between the function and pname fields.
	3. Deference that Q-POINTER to a string.
	4. Dump the string.

Not have source code yet, I didn't bother doing this.  One function is as
interesting as another right now.

Btw, the SET-NIL PDL makes sense.  Sect20 says that the offset is unused
when PDL base register is used.  Thus SET-NIL PDL basically means, PUSH NIL.
Which is exactly what we want.  The only argument that can be made is: "Does
PDL as a dest mean push or set".  Sect20 clearly indicates that PDL as a
source is a POP, but makes no mention of PDL as a target.  Given the
symmetry of the thing, I guess that it's a push.  If I'm wrong, then it's a
set.  I'd bet a quarter it's a push though.

SSDN2 is also pretty good about discussing the PDL.  The emulator should be
able to set the base and PDL pointers to say 1023.  The first instruction
would push NIL, i.e.

	1. PP = (PP + 1) % 1024
	2. PDL(PP) = NIL

There is a comment (I forget where) that indicates that overflow/underflow
checking can be done at CALL- time.  I hope so, that will make things a bit
faster to emulator.

We also know:

	1. Stack grow up (not down)
	2. We have a picture of a stack frame, which looks like:

		Args for Fn
		Saved regs for Fn-1
		Locals for Fn
		Temps for Fn
		Args for Fn+1
		Saved regs for Fn
		Locals for Fn+1
		Temps for Fn+1
			.
			.
			.

	Dave

-----Original Message-----
From: lispm-hackers-admin@lists.unlambda.com
[mailto:lispm-hackers-admin@lists.unlambda.com]On Behalf Of James A.
Crippen
Sent: Sunday, March 03, 2002 4:01 AM
To: lispm-hackers@lists.unlambda.com
Subject: Re: [LispM-Hackers] First Function


Paul Fuqua <pf@ti.com> writes:

> 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:

Has anyone ever chased the 'pointer_to_debugging_info_q' for the
initial function to see what it contains?  I'd do it now but I'm too
tired and would get confused.  It'd be interesting to see if the
debugging info contained anything useful, like what the original
function name was (and perhaps what file it came from).

If the first thing being done by the initial function is
LISP-REINITIALIZE then we're in for some fun.  We're going to
encounter *lots* of symbols scattered all over the planet when we hit
that.  Also there's that HARDWARE-BOOT-INITIALIZATIONS function that I
don't like at all.  We may have to do something fancy to skip over it
and pretend that it succeeded because it's writing to the NuBus in
real memory.

The cruft for MP systems is superfluous for us.  Hopefully MP-SYSTEM-P
defaults to NIL in the usual load band?

'james

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

http://lists.unlambda.com/mailman/listinfo/lispm-hackers