Self 4.1 added a few bytecodes to the 4.0 set in order to make
interpreters simpler. I see that in Self 2017.1 we have one more:
argumentCount. Not having to count colon characters in a string should
certainly make an interpreter much faster even if each send grows by one
bytes (so going from 5 bytes, the bytecode plus the literal that is
rarely shared, so 6 bytes - just a 20% overhead).
The fact that multiple bytecode sets can be used in a single snapshot
complicates things, but the current Squeak/Pharo/Cuis VM has added this
capability as well. But it isn't clear to me how this is supposed to
work. If the very first bytecode in a method is the
INSTRUCTION_SET_SELECTION then its operand indicates what the rest of
the bytecodes are like, otherwise instruction set 0 is assumed.
My problem is that this special bytecode is defined as being the same as
the argumentCount bytecode. Isn't there a danger of some method using
the default bytecode but starting out with a send looking like it had an
explicit instruction set instead? I suppose that the bytecode compiler
could take care to never let this happen. The one method I examined did
start with bytecode 208.