Ok. We are all waiting for this to happen :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Aug 8, 2014, at 6:46 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi All,
as part of the Newspeak infrastructure we use at Cadence I implemented multiple bytecode set support and a lifting of the limits in a method on the number of literals and the span of branches about two years ago. This work involved adding a second interpretation to the bits in a method header, providing 16 bits of literal count. This was done by moving the primitive number out of the method header and into an optional callPrimitive bytecode, being the first bytecode of methods that have primitives.
Now in Spur I have the opportunity to use this expanded format for the exsting bytecode set as well. The SqueakV3 set does not use bytecode 139, which is convenient to use for its callPrimitiveBytecode. The advantage is that when and if a new bytecode set is added, as is planned for the Sista VMs, the VM will not have to test method headers to decide which format they're in, because there will only be one.
Alas I only just realised this last night, and implementing this for Spur now means that any existing Spur images will be invalid. But better I do this now than later, when Spur is in wide-spread use.
So this message is to warn you that any existing Spur images will have to be discarded and rebuilt soon, once I release new VMs. Apologies for the inconvenience. I do plan for the VMs to exit with a useful error message when loading Spur images with the old method header format, rather than just crashing. So I hope the transition won't be too painful. -- best, Eliot