Hi there,
I am trying to understand what the meaning and implementation of "thisContext" is. On a recent COG VM, "[ |a b| a:=b:=1. thisContext basicSize ] value" returns 3. Adding more temp vars increases that value. On a Cocoa VM (http://squeakvm.org/mac/release/Squeak%205.7.4.1.zip), the same code always returns 0. Also, "thisContext at: 1" etc. is out of bounds. Which one is correct? Any ideas? The reason why I am asking is because there is code that seems to rely on this (e.g. SystemTracer2>>writeContext:) and I am trying to get it running on RSqueak. Thanks, Matthias |
On 08.06.2015, at 15:45, matthias.springer <[hidden email]> wrote: > Hi there, > > I am trying to understand what the meaning and implementation of > "thisContext" is. > > On a recent COG VM, "[ |a b| a:=b:=1. thisContext basicSize ] value" returns > 3. Adding more temp vars increases that value. > > On a Cocoa VM (http://squeakvm.org/mac/release/Squeak%205.7.4.1.zip), the > same code always returns 0. Also, "thisContext at: 1" etc. is out of bounds. (This is a vanilla (ie non-StackVM) interpreter VM) > > Which one is correct? Any ideas? > > The reason why I am asking is because there is code that seems to rely on > this (e.g. SystemTracer2>>writeContext:) and I am trying to get it running > on RSqueak. > > Thanks, > Matthias > > > > -- > View this message in context: http://forum.world.st/Trying-to-understand-thisContext-tp4830938.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > |
In reply to this post by matthias.springer
Hi Matthias,
cc'ing vm-dev, because this is more of a VM question On Mon, Jun 8, 2015 at 6:45 AM, matthias.springer <[hidden email]> wrote: Hi there, That's correct. thisContext basicSize effectively answers the value of the stack pointer of a context. In Squeak (as opposed to, say, the BLueBook) the Interpreter was optimized by changing the garbage collector to never look at fields in a context past the stack pointer. In the blue book, thisContext basicSize answers the number of stack slots in the context, rather than the stack pointer, and the garbage collector might look beyond the stack pointer for reachable object references, but if pop nils out the top of stack, there should only ever be nils beyond the stack pointer. IMO, this difference could have been hidden in the VM and thisCOntext basicSize could have always answered a constant, but that's the current definition in Squeak/Pharo.
This is not a closure VM right? So while the code reads the same, the bytecode and implementation is quite different. In this VM, which has blue-book blocks, block arguments are popped into temporary variables in the home context by the block prolog, so that by the time thisCOntext is sent basicSize its stack is empty. So given the compilayion of blocks, this answer is also correct. What I suggest is that you write the following and examine the differences in the bytecode: { [ |a b| a:=b:=1. thisContext basicSize ] value. thisContext method symbolic }
Both. They differ because they implement blocks quite differently. You can read more on the difference in the implementations in http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ et al.
Again, let me instead suggest that you adapt the code in SpurBootstrap in the Cog package at http://source.squeak.org/VMMaker, instead of using SystemTracer. It is a lot more direct, and less hairy than an image tracing itself. -- best,
Eliot |
On 08.06.2015, at 21:57, Eliot Miranda <[hidden email]> wrote: > Hi Matthias, > > cc'ing vm-dev, because this is more of a VM question > > On Mon, Jun 8, 2015 at 6:45 AM, matthias.springer <[hidden email]> wrote: > Hi there, > > I am trying to understand what the meaning and implementation of > "thisContext" is. > > On a recent COG VM, "[ |a b| a:=b:=1. thisContext basicSize ] value" returns > 3. Adding more temp vars increases that value. > > That's correct. thisContext basicSize effectively answers the value of the stack pointer of a context. In Squeak (as opposed to, say, the BLueBook) the Interpreter was optimized by changing the garbage collector to never look at fields in a context past the stack pointer. In the blue book, thisContext basicSize answers the number of stack slots in the context, rather than the stack pointer, and the garbage collector might look beyond the stack pointer for reachable object references, but if pop nils out the top of stack, there should only ever be nils beyond the stack pointer. > > IMO, this difference could have been hidden in the VM and thisCOntext basicSize could have always answered a constant, but that's the current definition in Squeak/Pharo. > > > On a Cocoa VM (http://squeakvm.org/mac/release/Squeak%205.7.4.1.zip), the > same code always returns 0. Also, "thisContext at: 1" etc. is out of bounds. > > This is not a closure VM right? So while the code reads the same, the bytecode and implementation is quite different. In this VM, which has blue-book blocks, block arguments are popped into temporary variables in the home context by the block prolog, so that by the time thisCOntext is sent basicSize its stack is empty. So given the compilayion of blocks, this answer is also correct. > > What I suggest is that you write the following and examine the differences in the bytecode: > > { [ |a b| a:=b:=1. thisContext basicSize ] value. thisContext method symbolic } > > > Which one is correct? Any ideas? > > Both. They differ because they implement blocks quite differently. You can read more on the difference in the implementations in http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ et al. > > > > The reason why I am asking is because there is code that seems to rely on > this (e.g. SystemTracer2>>writeContext:) and I am trying to get it running > on RSqueak. > > Again, let me instead suggest that you adapt the code in SpurBootstrap in the Cog package at http://source.squeak.org/VMMaker, instead of using SystemTracer. It is a lot more direct, and less hairy than an image tracing itself. :( That always has been one of the most interesting if not intriguing parts of Squeak Best regards -Tobias |
Free forum by Nabble | Edit this page |