For instructions like SETPNZ, SETPORT, SETXFR, etc., where the parameter is encoded in the D field (000011 ZCN 1 CCCC DDnnnnnnn 011011111), does the non-immediate (N=0) encoding allow for using INDA/INDB? Put another way, are these instructuctions internally remapped as follows:
N -> I
DDnnnnnnn -> SSnnnnnnn
And if this is all true, then does this mean that the instruction is actually decoded in the same stage that INDA/INDB fix-ups occur (stage 2)?
For instructions like SETPNZ, SETPORT, SETXFR, etc., where the parameter is encoded in the D field (000011 ZCN 1 CCCC DDnnnnnnn 011011111), does the non-immediate (N=0) encoding allow for using INDA/INDB? Put another way, are these instructuctions internally remapped as follows:
N -> I
DDnnnnnnn -> SSnnnnnnn
And if this is all true, then does this mean that the instruction is actually decoded in the same stage that INDA/INDB fix-ups occur (stage 2)?
That funny-looking DDnnnnnn just shows that in the case of immediate, only the 7 LSBs are used, whereas all 9 bits are used for a register (which could be indirect).
While looking over my instruction table I found a couple of errors...
MUL and SCL and their shared instructions references to the i bit should refer to the r bit.
Opcodes 000011 references to the r bit should refer to the i bit
For the multitasking instructions and descriptions I think there should be a distinction in the naming between the hardware time slicing and software context switching. "Task" is used in naming of both mechanisms. This makes for difficult reading for anyone not already understanding of how it all works.
How about referring to, the nominally cooperative, software context switching as "tasks" and hardware time slicing as "threads"? Will need the instructions themselves relabelled too.
Now that I've found Ghostery I'm a bit more prepared to enable scripting on rare occasions ... well, I just tried it with Google Docs ... boy was that a shock! It reminds me of trying to do DTP with a 0.5 MIPS processor. I'm run a 3.3 GHz (>10000 MIPS?) processor with multi-GB/s RAM speed and still being blown away by how bad bloat gets! How did this document get built?
NoScript is back in lock down mode thank you very much.
Comments
N -> I
DDnnnnnnn -> SSnnnnnnn
And if this is all true, then does this mean that the instruction is actually decoded in the same stage that INDA/INDB fix-ups occur (stage 2)?
That funny-looking DDnnnnnn just shows that in the case of immediate, only the 7 LSBs are used, whereas all 9 bits are used for a register (which could be indirect).
MUL and SCL and their shared instructions references to the i bit should refer to the r bit.
Opcodes 000011 references to the r bit should refer to the i bit
P2_Instructions.spin
For the multitasking instructions and descriptions I think there should be a distinction in the naming between the hardware time slicing and software context switching. "Task" is used in naming of both mechanisms. This makes for difficult reading for anyone not already understanding of how it all works.
How about referring to, the nominally cooperative, software context switching as "tasks" and hardware time slicing as "threads"? Will need the instructions themselves relabelled too.
NoScript is back in lock down mode thank you very much.