XBYTE and RET issue *** SOLVED ***

TonyB_

Solved, please ignore.

A JMP (actually TJxx) with non-zero skip bits still active was the problem. To jump out of skipping code, always use EXECF with all skip bits zero.

Cluso99

Yes, having used skips, it begs the fact that we didn’t have a wider stack to save skip bit when calling subroutines. IIRC the skip gets suspended on a call and replaced on return, but I can see where a new loaded skip pattern within the call might have been nice. Another xbyte perhaps inside the call.
This would be nice for the Z80 which has special opposes which blow out to another 256 instructions in the next byte. There’s 3 or 4 of these.
Guess we should be grateful for what we have

TonyB_

@Cluso99 said:
Yes, having used skips, it begs the fact that we didn’t have a wider stack to save skip bit when calling subroutines. IIRC the skip gets suspended on a call and replaced on return, but I can see where a new loaded skip pattern within the call might have been nice. Another xbyte perhaps inside the call.

I agree, a 64-bit hardware stack in the future would be wide enough to save all possible remaining skip bits and would allow nested skipping, reducing code size without a doubt.

Calls from skipping code are not a problem as you are "safe" from the skip bits inside the routines. Jumps can be a real danger if you forget that skipping still applies after the jump.