[alt] behaviour in OP_STACK makes no sense.

[Y-Less]

OP_STACK is defined as:

STACK | value | ALT = STK, STK = STK + value

That means the current stack position is placed in to alt, then the stack is adjusted. This is used in two ways:

1. To shrink the stack after some usage. This will mean that after the call alt now points below the stack to invalid memory.

2. To expand the stack for more data. This will mean that after the call alt will point to the old data that was already on the stack.

I have never ever seen a good use for this behaviour - it makes perfect sense for OP_HEAP because that grows up, and so after expansion alt will point to the start of the new data. In this opcode it is entirely useless. Much better would be:

STK = STK + value, ALT = STK

When growing the stack, that will mean ALT now points to the start of the newly allocated data, ready for use. When shrinking the stack, that will mean ALT still points to valid memory.

I very frequently have to do:

#emit STACK 20
#emit STACK 0

Just to adjust the stack then get the new pointer. I've never once needed the old pointer (and on the rare case I did, could just swap those over). I know #emit isn't used, but I think it would benefit the compiler as well to already have the new memory locations.

[Thiadmer Riemersma]

You are correct. This is an error. It has been entirely without consequences, because so far, the Pawn compiler did not use the ALT register after a "stack" instruction.

[Y-Less]

I knew it was without consequence in the compiler, but I tend to do a lot of low-level assembly stuff (on an older version) and while I don't expect the bug to be back-ported, it has annoyed me a few times so I thought it worth mentioning.

[Thiadmer Riemersma]

Fixed in commit 66415f2.
Not backported to version 3.x, though.