EXECF (including XBYTE)
in Propeller 2
I can't see a reason why anyone would ever use EXECF with the first skip bit set to 1. Why would you ever jump deliberately to an instruction and not execute it, when you could jump directly to the first instruction that you do want to execute?
I've looked at the latest Spin2 interpreter and the first skip bit is 0 for every bytecode from 00 to FF (with only the last two unused). Therefore, I think it would be safe to assume the instruction at the jump address will be executed, in which case a skip bit of 0 could be inserted automatically at the start of the skip pattern.
This would give us 22 skippable instructions after the first, increasing the length of the skip sequence from 22 to 23. I've already hit the current limit of 22 in XBYTE.
I've looked at the latest Spin2 interpreter and the first skip bit is 0 for every bytecode from 00 to FF (with only the last two unused). Therefore, I think it would be safe to assume the instruction at the jump address will be executed, in which case a skip bit of 0 could be inserted automatically at the start of the skip pattern.
This would give us 22 skippable instructions after the first, increasing the length of the skip sequence from 22 to 23. I've already hit the current limit of 22 in XBYTE.
Comments
zpu_storesp_N '' use an EXECF mask to select just one of the wrlongs wrlong tos,ptrb[1] ' only one wrlong tos,ptrb[2] ' only one wrlong tos,ptrb[3] ' only one wrlong tos,ptrb[4] ' only one wrlong tos,ptrb[5] ' only one wrlong tos,ptrb[6] ' only one wrlong tos,ptrb[7] ' only one wrlong tos,ptrb[8] ' only one _ret_ rdlong tos,++ptrb ... ' from the opcode table {51} long zpu_storesp_N | %0_1111_1110 << 10 {52} long zpu_storesp_N | %0_1111_1101 << 10 {53} long zpu_storesp_N | %0_1111_1011 << 10 {54} long zpu_storesp_N | %0_1111_0111 << 10 {55} long zpu_storesp_N | %0_1110_1111 << 10 {56} long zpu_storesp_N | %0_1101_1111 << 10 {57} long zpu_storesp_N | %0_1011_1111 << 10 {58} long zpu_storesp_N | %0_0111_1111 << 10
All of those initial skip bits of 1 are avoidable, but if you don't want to change the opcode table then you could simply insert a NOP at the beginning:
zpu_storesp_N nop ' 1st skip bit = 0 automatically '' use an EXECF mask to select just one of the wrlongs wrlong tos,ptrb[1] ' only one wrlong tos,ptrb[2] ' only one wrlong tos,ptrb[3] ' only one wrlong tos,ptrb[4] ' only one wrlong tos,ptrb[5] ' only one wrlong tos,ptrb[6] ' only one wrlong tos,ptrb[7] ' only one wrlong tos,ptrb[8] ' only one _ret_ rdlong tos,++ptrb ... ' from the opcode table {51} long zpu_storesp_N | %0_1111_1110 << 10 {52} long zpu_storesp_N | %0_1111_1101 << 10 {53} long zpu_storesp_N | %0_1111_1011 << 10 {54} long zpu_storesp_N | %0_1111_0111 << 10 {55} long zpu_storesp_N | %0_1110_1111 << 10 {56} long zpu_storesp_N | %0_1101_1111 << 10 {57} long zpu_storesp_N | %0_1011_1111 << 10 {58} long zpu_storesp_N | %0_0111_1111 << 10
{52}..{58} would take the same time as now and {51}..{58} an identical time. Note that the NOP would not reduce the useable skip pattern length.
Existing patterns with first skip bits always 0 could also stay the same, as follows.
Before
long op_notb | %01111111101110 << 10 '7B !!exp long op_not | %011111110_____ << 10 '7C !exp long op_neg | %01111110______ << 10 '7D -exp long op_abs | %0111110_______ << 10 '7E ABS exp long op_ncod | %011110________ << 10 '7F ENCOD exp long op_dcod | %01110_________ << 10 '80 DECOD exp long op_ones | %0110__________ << 10 '81 ONES exp long op_sqrt | %0101111111110_ << 10 '82 SQRT exp long op_log | %010111111110__ << 10 '83 LOG exp long op_exp | %01011111110___ << 10 '84 EXP exp
After
long op_notb | %01111111101110 << 9 '7B !!exp long op_not | %011111110_____ << 9 '7C !exp long op_neg | %01111110______ << 9 '7D -exp long op_abs | %0111110_______ << 9 '7E ABS exp long op_ncod | %011110________ << 9 '7F ENCOD exp long op_dcod | %01110_________ << 9 '80 DECOD exp long op_ones | %0110__________ << 9 '81 ONES exp long op_sqrt | %0101111111110_ << 9 '82 SQRT exp long op_log | %010111111110__ << 9 '83 LOG exp long op_exp | %01011111110___ << 9 '84 EXP exp
This is about EXECF in XBYTE, which wouldn't have random masks and dynamically created skip patterns.
A JIT compiler might create an XBYTE interpreter on the fly. Or, more likely, a compiler running on the PC might create a custom interpreter based on the instructions it sees in the program. Both of which could work around the change you propose, of course. and in the abstract your idea's a good one. But it's rather late in the day for us to be changing the instruction set. I think Chip definitely has the right idea to leave well enough alone for now. I hope he does take your proposal into account for P3.