A bit technical this and perhaps not of much interest to anyone who isn't toying with hacking the Spin Interpreter and object code, but for those who are, this could be a useful discovery. 

Apologies if anyone has worked this out and announced it already but if they have I've missed it !

There are three Spin bytecodes which have had me intrigued for a long while ...

3FÊ80+nÊÊÊÊÊPUSHÊÊÊÊspr
3FÊA0+nÊÊÊÊÊPOPÊÊÊÊÊspr
3FÊC0+nÊÊÊÊÊUSINGÊÊÊspr

When n is $10 to $1F these allow Spin to access the Special Purpose Registers at $1F0 to $1FF ( INA, OUTA, DIRA etc ), when n is $00 to $0F they perform another function, for example, to push the current Cog ID to the stack ...

3FÊ89ÊÊÊÊÊÊÊPUSHÊÊÊÊ$09

I knew about the '$3F 9x' opcodes, but '$3F 8x' remained a mystery. Working on the latest bytecode disassembler I set about trying to fill in the gaps.

Looking at the Spin Interpreter source; what do we find at $1E9 ? "id", which is set early on in the interpreter initialisation and never otherwise used within the interpreter ( I had wondered why that was ).

Obvious with hindsight and when the light comes on; +n is +$00 to +$1F accessing Cog Ram $1E0 to $1FF which just happens to include the SPR. A typical Chip optimisation ( I recall I did say getting into Chip's head was a big key to cracking and understanding the interpreter ).

Now, what do we see after "id" ? The variables the interpreter itself uses; program counter, stack pointer, object base, variable base, etc.

So a few things ...

1) For people writing their own Spin Interpreters, it's crucial that Cog Ram at $1E9-$1EF is used exactly as in the ROM Interpreter or the '$3F xx' opcodes are abstracted to behave as they would if placed elsewhere. That explains why attempts to move or remove any of those variables lead to a crash of a hub-loaded interpreter.

2) Reading Cog Ram from $1E0 to $1EF should be possible ( assuming we can put the required bytecode into the image ) so it's possible to determine current stack base, current stack pointer, current PC etc without jumping through convoluted hoops in Spin.

3) If we can read Cog Ram we can write it, which opens the door to some potentially clever tricks with altering stack and PC on the fly, all of which could be useful for DOL and other 'bootload object', and 'object overlay' hackery.

4) As we can write to $1E0 through $1EF, there's a good chance we could inject code into the interpreter which we can force to be executed; we can overwrite part of the 'range' routine.. That would allow injected code to dump the entire interpreter from Cog Ram ( irrelevant now, and a catch 22 ! ), but an attack vector Chip will probably want to close for the Prop II.

5) More importantly with code injection, it should be possible to switch a running interpreter to an LMM interpreter and back again, or even switch it to running in-line PASM !

I haven't had a chance to try this yet but looking at the interpreter source it appears to hold up as a valid analysis.