<br><br><div class="gmail_quote">On Wed, Apr 13, 2011 at 3:42 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@angband.za.org">frank.shearar@angband.za.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 2011/04/13 23:19, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Frank,<br>
<br>
you're committing a category error. The space of bytecodes is<br>
disjoint from the space of numbered primitives and they are entirely<br>
unrelated. The implementation of primitive 199 is given in e.g.<br>
Interpreter class>>initializePrimitiveTable and is<br>
primitiveMarkHandlerMethod, which itself is implemented as<br>
primitiveFail, since (as the comment says) primitive 199 is only used to<br>
mark a method as being an unwind-protect, not to change its invocation<br>
semantics. Bytecode 199 is indeed bytecodePrimClass and causes the VM<br>
to fetch the class of the receiver (i.e. it is short-hand for sending<br>
#class to the receiver, except that the message isn't looked up, and so<br>
can't be overridden). The sace of bytecodes is defined by e.g.<br>
Interpreter class>>intiializeBytecodeTable. Compare e.g. primitive 60<br>
to bytecode 60 and the distinction should become clearer.<br>
</blockquote>
<br></div>
Ah! That was a silly mistake. I found initializeBytecodeTable by searching for methods containing '199', and leapt to my great confusion.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
BTW, you should focus your understanding on how contexts work<br>
(ContextPart & MethodContext). That's the fundamental, and above<br>
contexts exceptions are implemented. Anyone have a pointer to Peter<br>
Deutsch's article on contexts ion the 1981 Byte issue? That's a good<br>
place to start. Another place is the Blue Book's implementation chapter.<br>
</blockquote>
<br></div>
I have a fair idea on how contexts work, although I still need to figure out/find out how (and when) contexts are actually created. (More reading of VMMaker source is required.)<br></blockquote><div><br></div><div>Effectively contexts are created when messages are activated. Method evaluation (see internalExecuteNewMethod and executeNewMethod) is a two step process, primitive evaluation followed optionally by method activation. First the new method is examined to find out if it has a primitive, and if it has then that primitive is executed. If the primitive succeeds then its result is returned to the sender and execution continues, without activating the method. If the primitive fails then the method is activated as if it had no primitive. A method is activated by creating a new context, initialized with the new method, and the sender as the new context's sender, moving the receiver and arguments of the message send from the sender context to the new context and then continuing execution in the new context. See the <a href="http://www.mirandabanda.org/bluebook/bluebook_chapter27.html#Contexts27">section Contexts in the Blue Book</a>. </div>
<div><br></div><div>Note, however that an efficient Smalltalk VM will /not/ create contexts on activation, but defer creation until a context is referenced by the running program, e.g. when creating a BlockClosure (the context being the closure's home context), or when the programmer uses the thisContext pseudo-variable explicitly. That's one reason why Cog (and indeed the VisualWorks VM) is much faster than the Interpreter. And <a href="http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/">this</a> goes into the gory details.</div>
<div><br></div><div>HTH,</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
(At any rate, I know enough to have implemented a rough working implementation of shift/reset.)<br>
<br>
Randal mentions <a href="https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.pdf" target="_blank">https://gforge.inria.fr/frs/download.php/26600/PBE2-Exceptions-2010-03-02.pdf</a> and indeed, on page 24 I see what I _should_ have been looking at, namely _primitive_ 199, not _bytecode_ 199.<br>
<br>
I see that, for instance, using primitives to search for the handler context won't create more contexts in the call stack. When you're manipulating the current call stack that can be quite important, I would imagine?<br>
<br>
But I suppose I'm really asking this: is it _necessary_ to use primitive 199, or could one in _principle_ implement exception handling solely by in-image stack manipulation?<br></blockquote><div><br></div><div>The VM needs to implement unwind-protect; one can't do that using in-image manipulation, and unwind-protect is indicated by marking with primitive 198. But other than that, the use of the exception tag primitive 199 is just an optimization, allowing the VM to perform relatively efficient search for handlers.</div>
<div><br></div><div>best,</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
<br>
frank<br>
<br>
</font><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Apr 13, 2011 at 3:07 PM, Frank Shearar<br></div><div><div></div><div class="h5">
<<a href="mailto:frank.shearar@angband.za.org" target="_blank">frank.shearar@angband.za.org</a> <mailto:<a href="mailto:frank.shearar@angband.za.org" target="_blank">frank.shearar@angband.za.org</a>>> wrote:<br>
<br>
I'm playing around with Danvy and Filinski's shift/reset operators,<br>
which allow a nice (lexically scoped) syntax for capturing partial<br>
continuations.<br>
<br>
In particular, reset marks the stack in some way, and a later shift<br>
reifies the call stack between itself and reset as a function.<br>
<br>
To that end, I'm delving into the guts of how exceptions work. I've<br>
a few questions:<br>
<br>
First, I know that VMMaker (especially Interpreter<br>
class>>initializeBytecodeTable) lists all the known numbered<br>
primitives. In particular, BlockClosure>>on:do: uses <primitive: 199>.<br>
<br>
on: exception do: handlerAction<br>
"Evaluate the receiver in the scope of an exception handler."<br>
<br>
| handlerActive |<br>
<primitive: 199> "just a marker, fail and execute the following"<br>
handlerActive := true.<br>
^ self value<br>
<br>
and<br>
<br>
bytecodePrimClass<br>
| rcvr |<br>
rcvr := self internalStackTop.<br>
self internalPop: 1 thenPush: (self fetchClassOf: rcvr).<br>
self fetchNextBytecode.<br>
<br>
is the implementation of that bytecode.<br>
<br>
But what's this really doing? Or, rather, how is what it's doing<br>
connected with marking a context so as to find an exception handler?<br>
<br>
If it's purely a marker, could one use another primitive? (Other<br>
than "that's how we do it, and Things Will Break if something<br>
changes the primitive number". I can only find<br>
MethodContext>>isHandlerContext caring about the particular<br>
primitive number)<br>
<br>
Could one, in principle at least, lose the primitive invocation and<br>
have an instvar isHandlerContext on ContextPart (MethodContext, more<br>
likely), and just repeatedly walk down the stack to find the handler<br>
rather than using another primitive to find the handler?<br>
<br>
Secondly, what's handlerActive for in #on:do:? It's a local variable<br>
set and then never referenced. (No other method has 'handlerActive'<br>
in its source, in the base image.)<br>
<br>
Thanks!<br>
<br>
frank<br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote>
<br>
<br>
</blockquote></div><br>