Hi Frank,

    you're committing a category error.  The space of bytecodes is disjoint
from the space of numbered primitives and they are entirely unrelated.  The
implementation of primitive 199 is given in e.g. Interpreter
class>>initializePrimitiveTable and is primitiveMarkHandlerMethod, which
itself is implemented as primitiveFail, since (as the comment says)
primitive 199 is only used to mark a method as being an unwind-protect, not
to change its invocation semantics.  Bytecode 199 is indeed
bytecodePrimClass and causes the VM to fetch the class of the receiver (i.e.
it is short-hand for sending #class to the receiver, except that the message
isn't looked up, and so can't be overridden).  The sace of bytecodes is
defined by e.g. Interpreter class>>intiializeBytecodeTable.  Compare e.g.
primitive 60 to bytecode 60 and the distinction should become clearer.

BTW, you should focus your understanding on how contexts work (ContextPart &
MethodContext). That's the fundamental, and above contexts exceptions are
implemented.  Anyone have a pointer to Peter Deutsch's article on contexts
ion the 1981 Byte issue?  That's a good place to start.  Another place is
the Blue Book's implementation chapter.

HTH,
Eliot

On Wed, Apr 13, 2011 at 3:07 PM, Frank Shearar <frank.shearar at angband.za.org
> wrote:

> I'm playing around with Danvy and Filinski's shift/reset operators, which
> allow a nice (lexically scoped) syntax for capturing partial continuations.
>
> In particular, reset marks the stack in some way, and a later shift reifies
> the call stack between itself and reset as a function.
>
> To that end, I'm delving into the guts of how exceptions work. I've a few
> questions:
>
> First, I know that VMMaker (especially Interpreter
> class>>initializeBytecodeTable) lists all the known numbered primitives. In
> particular, BlockClosure>>on:do: uses <primitive: 199>.
>
> on: exception do: handlerAction
>        "Evaluate the receiver in the scope of an exception handler."
>
>        | handlerActive |
>        <primitive: 199>  "just a marker, fail and execute the following"
>        handlerActive := true.
>        ^ self value
>
> and
>
> bytecodePrimClass
>        | rcvr |
>        rcvr := self internalStackTop.
>        self internalPop: 1 thenPush: (self fetchClassOf: rcvr).
>        self fetchNextBytecode.
>
> is the implementation of that bytecode.
>
> But what's this really doing? Or, rather, how is what it's doing connected
> with marking a context so as to find an exception handler?
>
> If it's purely a marker, could one use another primitive? (Other than
> "that's how we do it, and Things Will Break if something changes the
> primitive number". I can only find MethodContext>>isHandlerContext caring
> about the particular primitive number)
>
> Could one, in principle at least, lose the primitive invocation and have an
> instvar isHandlerContext on ContextPart (MethodContext, more likely), and
> just repeatedly walk down the stack to find the handler rather than using
> another primitive to find the handler?
>
> Secondly, what's handlerActive for in #on:do:? It's a local variable set
> and then never referenced. (No other method has 'handlerActive' in its
> source, in the base image.)
>
> Thanks!
>
> frank
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110413/3690585c/attachment.htm