[LMH]Exploiter progress

[Nyef]

On Thu, 11 Sep 2003, James A. Crippen wrote:

> Nyef <nyef@softhome.net> writes:
> 
> > Instance funcalling is semi-working. It always calls 
> > INSTANCE-HASH-FAILURE, which in turn calls the required method. SELF is 
> 
> Nice hack. It's crude, but hey.

Well, I figure that since it's an existing fallback for when the microcode 
can't find the method it's legitimate to have the microcode never find the 
method. I'll admit that at least trying to do a lookup would be more 
elegant, but it's more of an optimization than an essential operation.

> > being bound, but the rest of the flavor bindings aren't. The binding of 
> > SELF is being done after the invocation of INSTANCE-HASH-FAILURE, rather 
> > than before, and is being done as the first binding in the function's 
> > frame rather than as a separate closure binding prior to invocation.
> 
> Is this because the band's code does this binding beforehand, or is it
> a problem with the exploiter?

This is a problem with exploiter. I need to work up a good model of how 
the SPDL is really supposed to be laid out, and make sure that it works 
that way consistently in exploiter.

> > Method function invocation is semi-working. The self-mapping-table isn't 
> > being bound, but the functions invoke well enough for now.
> 
> I still dont quite grok what the SMT is for... Anyone have a good
> explanation for an idiot?

I'm under the impression that the SMT is for dealing with multiple 
inheritance or mixins or both without having to recompile the base methods 
specalized for each class. So far nothing has tried doing a mapped SELF 
access, so I'm not too worried about it.

> > Let me say that again: We're at the first stack group switch.
> 
> Let me say this: You kick ass!

Thank you. ^_^

> I can't believe that we're trying to switch stack groups. It's
> awesome. The start of multitasking. Very cool.

I can't believe it either. I also have this uneasy feeling that all of the
hacks in the system are going to conspire together to cause a lot of
trouble in the near future. Of course, I've been feeling that off and on
since exploiter started becoming a serious project rather than a little
hack to figure out how function calling works.

The diagnostic output is getting verbose enough that I want to start 
disabling some of it, but I don't dare because it will become completely 
impossible to track down any of the more subtle bugs the instant I take 
anything out.

I'm going to be proceeding under the assumption that a task switch saves
off the machine state, undoes every binding on the SPDL in reverse order
of initial binding, loads the new machine state, and then does up every
binding on the SPDL again in order of initial binding. This is roughly 
analagous to how CMUCL does it and how SBCL used to do it (before dan_b 
put in the native multithread changes).

> 'james

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net