SKIPF when skipping already active
TonyB_
Posts: 2,127
There is an issue/trap with SKIPF, likely due to instruction pipelining:
If SKIPF {#}D is executed during a skip sequence then the next instruction will not be executed if the original/old skip bit for that instruction = 1. The next instruction will be executed if the old skip bit = 0 and the new skip bit in D[0] = 0.
This applies to the 2-cycle instructions tested, ADD and ZEROX. If the next instruction is RDWORD, which takes at least 9 cycles, then it will be executed if just the old skip bit = 0.
I suspect this issue does not apply to _RET_ SKIPF {#},D nor EXECF {#}D due to pipeline reload after branching but I have not tested these.
EDIT:
Info updated.
Comments
Well, thanks for the research!
Another oddity (though not necessarily an issue) I remember I've encountered: RET while SKIP is active doesn't cancel/suspend it. So the suspend counter saturates at the bottom. Wonder what happens when the suspend counter overflows.
From memory, a 3-bit skip call counter increments for each call, decrements for each ret and a non-zero value suspends skipping. Makes huge amount of sense for counter not to decrement if zero. I don't know what happens to counter if there is a call when it is 7 but hardware stack overflowing should discourage that.
The SKIPF info above is the result of a bug hunt, not planned research. I've done more testing and edited the first post accordingly. The new skip bit 0 being ignored completely is a rather disconcerting. Something to add to the doc and perhaps confirm by somebody else.
More testing shows this bit is not always ignored. Please see re-edited first post for details.
I think I don't understand your edit - case (a) as worded seems to also cover case (b). It seems to say that in either case, the next instruction is executed iff the original skip bit = 0. How is that any different from your original finding?
To execute next instruction after SKIPF:
(a) Original skip bit = 0 in one case
(b) Original skip bit = 0 and new skip bit = 0 in another case
Why sometimes (a), sometimes (b) I do not know.
First post edited to reduce confusion.
I understand skip as something that works with a hidden shift register. It loads the register and then gets one bit for every next 32 instructions. I don't think there is a logic which counts leading zeros in the skip pattern so the skip always works for the next 32 instructions. Then if there is 1 in the skip patern, the internal logic is designed to always catch this case and that's why the first skipped instruction always takes 2 cycles, skipped or not.
A ret instruction in the skip pattern is simply a instruction. One of 32 in the pattern.
A nested skip in this model reloads the skip register with new data, but there is a pipeline which is already executing, and the old skip pattern bit was already latched, so I would expect such kind of anomalies.
What I would expect here, is:
What instructions are (a) case and what instructions are (b) case?
A workaround here is add a nop after nested skip to give the P2 time to reload the skip pattern register.
We need Chip here. He designed the chip and knows exactly how skip instruction works inside a P2.
More testing done and first post amended. If old skip bit = 1 next instruction always skips. If old = 0 and new = 1 there is a race/conflict that depends on instruction time: new bit wins if 2 cycles; old bit wins if 9+ cycles.