Why is pulling from the stack on the 65816 always one cycle slower than pushing that same register to the stack?

I tend to think of these operations as pseudo-inverses of each other. Pushing and then pulling, or pulling and then pushing, generally restores the stack to the state it was before, but only pushing and then pulling keeps the state of the register the same; pulling and then pushing a register discards its old value.

But these operations still seem quite symmetric - what is the extra cycle spent doing during a pull?

It's the increment of the Stack Pointer. As you know, S points to the next available location -- not to the top item. So, to pull the top item, S must be incremented before the item is read. This consumes one cycle.

(For a push, the decrement of S happens after the write has occurred... and the decrement can be overlapped with the fetch of the next opcode, making it appear to consume zero cycles.)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

That explains a bit; always wondered about that myself.

Very fascinating. I would be interested in seeing what parts of the processor can be engaged simultaneously during a single clock cycle. Since do a lot of adjacent pulls is so slow, I'm finding it useful to create stack unwinding macros that increment the stack pointer back to where it was at the beginning of the subroutine.

Not really - I just wanted to speed up restoring the stack pointer.

You can use TSX and then save X somewhere, so then you can use TXS to restore the previous stack pointer.

Possibly you can even store the previous stack pointer on the stack, after having put the things you want on there.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think it's fairly normal, isn't it, to have a stack frame and to push the previous value?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Well, one of us is confused!

I don't arbitrarily change the stack pointer. I use the stack for automatic variables like in C, and I can tell at edit-time how many bytes I have allocated, so stack unwinding becomes simply incrementing the stack pointer up that many bytes.

Had you considered saving and restoring it with TSX and TXS?

Yes that is how one of my stack unwinding macros works.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!