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
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.