On Tue, Mar 10, 2009 at 12:48 AM, Klaus D. Witzel klaus.witzel@cobss.comwrote:
Hi Eliot,
On Tue, 10 Mar 2009 01:04:29 +0100, Eliot Miranda wrote:
Hi Klaus,
On Mon, Mar 9, 2009 at 11:04 AM, Klaus D. Witzel wrote:
...
I've seen that one of the differences between the Encoder*XYZ's is
#supportsClosureOpcodes being true/false but also #generateAsClosure plays a role. So the *Closures suffix is short for *EmitClosuresBytecode? Also, blocks are never emitted the old (non-closure) way?
The scheme is that by choosing the encoder one can choose the type of code generated. So that e.g. if you say
(Parser new encoderClass: EncoderForV3PlusClosures; parse: someString readStream class: MyClass) generate: #(0 0 0 0)
you'll get closure code and if you say
(Parser new encoderClass: EncoderForV3; parse: someString readStream class: MyClass) generate: #(0 0 0 0)
you'll get pre-closure old-block code.
Okay thanks, perfectly clear now.
...
And on the wrong VM it'll crash. Only the CLosure VM that people are
providing right now can run both new and old code. The StackVM we have in Qwaq (that I hope will be released sometime) will only run Closure code and die horribly if given old block code.
This implies that any test*ABC method which compiles source code and passes the wrong Encoder*XYZ to Parser can crash its VM. So one has to check, in such tests, what VM type is running. How can the VM be queried for that?
Good point. There isn't a straight-forward way in the normal VMs. In the Qwaq internal VMs I added the imageFormatVersion of the current VM as vm parameter #41. BTW, here is the complete list of things I've added
41 imageFormatVersion for the VM 42 nil (number of stack pages in use in Stack VM) 43 nil (desired number of stack pages in Stack VM) 44 nil (size of eden, in bytes in Stack VM) 45 nil (desired size of eden in Stack VM) 46-55 nil; reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck calls since startup (read-only) 59 number of check event calls since startup (read-only)
There might be a way of constructing an empty closure on a null method and testing if a version of the closure primitive fails, but I prefer the image format parameter. In older VMs the vm parameter primitive should fail if given parameter 41. What say the VM devs? Can we add #41 as answering the imageFormatVersion of the VM?
/Klaus
-- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein
Eliot Miranda wrote:
Good point. There isn't a straight-forward way in the normal VMs. In the Qwaq internal VMs I added the imageFormatVersion of the current VM as vm parameter #41. BTW, here is the complete list of things I've added
41 imageFormatVersion for the VM 42 nil (number of stack pages in use in Stack VM) 43 nil (desired number of stack pages in Stack VM) 44 nil (size of eden, in bytes in Stack VM) 45 nil (desired size of eden in Stack VM) 46-55 nil; reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck calls since startup (read-only) 59 number of check event calls since startup (read-only)
There might be a way of constructing an empty closure on a null method and testing if a version of the closure primitive fails, but I prefer the image format parameter. In older VMs the vm parameter primitive should fail if given parameter 41. What say the VM devs? Can we add #41 as answering the imageFormatVersion of the VM?
Sounds reasonable to me (but then I may be biased ;-)
Cheers, - Andreas
vm-dev@lists.squeakfoundation.org