Thu Sep 11 12:13:01 2003
On Thu, 11 Sep 2003, James A. Crippen wrote:
> Nyef <email@example.com> 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
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).
All programming can be viewed as an exercise.