Minor curiosity & clueless speculation... in passing I came across the following in #handleCallOrJumpSimulationTrap and given the similarity of critical section and ownedlock primitives to alter the running process like primitiveWait, I wondered if they should also be in this list ...
"Verify the stack layout assumption compileInterpreterPrimitive: makes, provided we've not called something that has built a frame, such as closure value or evaluate method, **or switched frames**, such as primitiveSignal, primitiveWait, primitiveResume, primitiveSuspend et al."
ifTrue: [(#( primitiveClosureValue primitiveClosureValueWithArgs primitiveClosureValueNoContextSwitch primitiveFullClosureValue primitiveFullClosureValueWithArgs primitiveFullClosureValueNoContextSwitch primitiveSignal primitiveWait primitiveResume primitiveSuspend primitiveYield primitiveExecuteMethodArgsArray primitiveExecuteMethod primitivePerform primitivePerformWithArgs primitivePerformInSuperclass primitiveTerminateTo primitiveStoreStackp primitiveDoPrimitiveWithArgs)
cheers -ben
Hi Ben,
The primitives present here are the primitives which create a new stack frame or switch to another one.
In your new primitives: - do you create a new stack frame ? For example, primitiveClosureValue creates a new stack frame for the block evaluation. I don't think that is the case. - do you potentially switch to another process ? For example, primitiveResume may switch execution to the resumed process if it has a higher priority, so the active stack frame may have changed. It could be that you have primitives like that.
I'd recommend you not to change that method right now. Instead, you implement your code, then run it in the VM simulator to ensure everything works fine. If the simulator halts in handleCallOrJumpSimulationTrap, then add your primitive here if relevant, else just ignore that method. Changing this method ahead of time doesn't feel like a good idea.
Have fun :-)
On Fri, May 20, 2016 at 1:46 PM, Ben Coman btc@openinworld.com wrote:
Minor curiosity & clueless speculation... in passing I came across the following in #handleCallOrJumpSimulationTrap and given the similarity of critical section and ownedlock primitives to alter the running process like primitiveWait, I wondered if they should also be in this list ...
"Verify the stack layout assumption compileInterpreterPrimitive: makes, provided we've not called something that has built a frame, such as closure value or evaluate method, **or switched frames**, such as primitiveSignal, primitiveWait, primitiveResume, primitiveSuspend et al."
ifTrue: [(#( primitiveClosureValue primitiveClosureValueWithArgs primitiveClosureValueNoContextSwitch primitiveFullClosureValue primitiveFullClosureValueWithArgs primitiveFullClosureValueNoContextSwitch primitiveSignal primitiveWait primitiveResume primitiveSuspend primitiveYield primitiveExecuteMethodArgsArray primitiveExecuteMethod primitivePerform primitivePerformWithArgs primitivePerformInSuperclass primitiveTerminateTo primitiveStoreStackp primitiveDoPrimitiveWithArgs)
cheers -ben
On Fri, May 20, 2016 at 8:44 PM, Clément Bera bera.clement@gmail.com wrote:
Hi Ben,
The primitives present here are the primitives which create a new stack frame or switch to another one.
In your new primitives:
- do you create a new stack frame ? For example, primitiveClosureValue creates a new stack frame for the block evaluation. I don't think that is the case.
Correct. It doesn't create a stack frame.
- do you potentially switch to another process ?
It does when trying to acquire a lock held by someone else, the process sleeps and does wakeHighestPriority to which it transferTo:
For example, primitiveResume may switch execution to the resumed process if it has a higher priority, so the active stack frame may have changed. It could be that you have primitives like that.
I'd recommend you not to change that method right now. Instead, you implement your code, then run it in the VM simulator to ensure everything works fine. If the simulator halts in handleCallOrJumpSimulationTrap, then add your primitive here if relevant, else just ignore that method. Changing this method ahead of time doesn't feel like a good idea.
Thanks for the tip. I hadn't come across that method yet. I had already decided to try and get the simulator working for the first time this weekend. Its been interesting poking through the VM with gdb, but its not "exactly" fun.
cheers -ben
Have fun :-)
On Fri, May 20, 2016 at 1:46 PM, Ben Coman btc@openinworld.com wrote:
Minor curiosity & clueless speculation... in passing I came across the following in #handleCallOrJumpSimulationTrap and given the similarity of critical section and ownedlock primitives to alter the running process like primitiveWait, I wondered if they should also be in this list ...
"Verify the stack layout assumption compileInterpreterPrimitive: makes, provided we've not called something that has built a frame, such as closure value or evaluate method, **or switched frames**, such as primitiveSignal, primitiveWait, primitiveResume, primitiveSuspend et al."
ifTrue: [(#( primitiveClosureValue primitiveClosureValueWithArgs primitiveClosureValueNoContextSwitch primitiveFullClosureValue primitiveFullClosureValueWithArgs primitiveFullClosureValueNoContextSwitch primitiveSignal primitiveWait primitiveResume primitiveSuspend primitiveYield primitiveExecuteMethodArgsArray primitiveExecuteMethod primitivePerform primitivePerformWithArgs primitivePerformInSuperclass primitiveTerminateTo primitiveStoreStackp primitiveDoPrimitiveWithArgs)
cheers -ben
On Fri, May 20, 2016 at 7:29 PM, Ben Coman btc@openinworld.com wrote:
On Fri, May 20, 2016 at 8:44 PM, Clément Bera bera.clement@gmail.com wrote:
Hi Ben,
The primitives present here are the primitives which create a new stack
frame or switch to another one.
In your new primitives:
- do you create a new stack frame ? For example, primitiveClosureValue
creates a new stack frame for the block evaluation. I don't think that is the case.
Correct. It doesn't create a stack frame.
- do you potentially switch to another process ?
It does when trying to acquire a lock held by someone else, the process sleeps and does wakeHighestPriority to which it transferTo:
For example, primitiveResume may switch execution to the resumed process
if it has a higher priority, so the active stack frame may have changed. It could be that you have primitives like that.
I'd recommend you not to change that method right now. Instead, you
implement your code, then run it in the VM simulator to ensure everything works fine. If the simulator halts in handleCallOrJumpSimulationTrap, then add your primitive here if relevant, else just ignore that method. Changing this method ahead of time doesn't feel like a good idea.
Thanks for the tip. I hadn't come across that method yet. I had already decided to try and get the simulator working for the first time this weekend. Its been interesting poking through the VM with gdb, but its not "exactly" fun.
Normally if you build a cog development image: $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image $ cd ./image $ ./buildsqueaktrunkvmmakerimage.sh
You have multiple scripts available with comments to run the simulator that work out of the box. It should take a couple minutes to get it working. Then the easiest is to simulate a REPL image to easily debug what you want.
cheers -ben
Have fun :-)
On Fri, May 20, 2016 at 1:46 PM, Ben Coman btc@openinworld.com wrote:
Minor curiosity & clueless speculation... in passing I came across the following in #handleCallOrJumpSimulationTrap and given the similarity of critical section and ownedlock primitives to alter the running process like primitiveWait, I wondered if they should also be in this list ...
"Verify the stack layout assumption compileInterpreterPrimitive: makes, provided we've not called something that has built a frame, such as closure value or evaluate method, **or switched frames**, such as primitiveSignal, primitiveWait, primitiveResume, primitiveSuspend et al."
ifTrue: [(#( primitiveClosureValue primitiveClosureValueWithArgs primitiveClosureValueNoContextSwitch primitiveFullClosureValue primitiveFullClosureValueWithArgs primitiveFullClosureValueNoContextSwitch primitiveSignal primitiveWait primitiveResume primitiveSuspend
primitiveYield
primitiveExecuteMethodArgsArray primitiveExecuteMethod primitivePerform primitivePerformWithArgs primitivePerformInSuperclass primitiveTerminateTo primitiveStoreStackp primitiveDoPrimitiveWithArgs)
cheers -ben
vm-dev@lists.squeakfoundation.org