RDBYTE instruction encoding, 78rpm error (likely) or PNut?
78rpm
Posts: 264
in Propeller 2
I am still sorting out the RDBYTE, WORD, LONG, WRBYTE etc testing. I am synthesising the instructions, and I also generate a textual list of all possible instructions / indices. The generated text is cut and pasted from PST to PNut. PNut assembles without complaint, but the binary code generated is different to the code I generate.
Here is a one test code. Note, this is not an execution error with this varient of RDBYTE, it is merely a discrepency error between my synthesis and PNut encoding.
Here, snipped from the docs, is the table for encoding:
According to the penultimate line in the table above, bit 5 for a --ptra[n] should be 0. Which to me looks like a PNut error / problem / oversight / typo.
rdbyte x, --ptrb[ n ] exhibits the same difference in encoding and I flag it as an error.
Thank you for verifying this for / with me.
Here is a one test code. Note, this is not an execution error with this varient of RDBYTE, it is merely a discrepency error between my synthesis and PNut encoding.
Test number 174 rdbyte x, --ptra [ 1] Error, synthesis != PNut, syn = $fb06575f PNut says = $fb06577f
Here, snipped from the docs, is the table for encoding:
POINTER ADDRESSING MODES INDEX = -16..+15 for simple offsets, 0..15 for ++'s, or 0..16 for --'s SCALE = 1 for byte, 2 for word, 4 for long S = 0 for PTRA, 1 for PTRB U = 0 to keep PTRx same, 1 to update PTRx P = 0 to use PTRx + INDEX*SCALE, 1 to use PTRx (post-modify) NNNNN = INDEX nnnnn = -INDEX 1SUPNNNNN PPTTRR eexxpprreessssiioonn ------------------------------------------------------------------------------ 100000000 PTRA 'use PTRA 110000000 PTRB 'use PTRB 101100001 PTRA++ 'use PTRA, PTRA += SCALE 111100001 PTRB++ 'use PTRB, PTRB += SCALE 101111111 PTRA-- 'use PTRA, PTRA -= SCALE 111111111 PTRB-- 'use PTRB, PTRB -= SCALE 101000001 ++PTRA 'use PTRA + SCALE, PTRA += SCALE 111000001 ++PTRB 'use PTRB + SCALE, PTRB += SCALE 101011111 --PTRA 'use PTRA - SCALE, PTRA -= SCALE 111011111 --PTRB 'use PTRB - SCALE, PTRB -= SCALE 1000NNNNN PTRA[INDEX] 'use PTRA + INDEX*SCALE 1100NNNNN PTRB[INDEX] 'use PTRB + INDEX*SCALE 1011NNNNN PTRA++[INDEX] 'use PTRA, PTRA += INDEX*SCALE 1111NNNNN PTRB++[INDEX] 'use PTRB, PTRB += INDEX*SCALE 1011nnnnn PTRA--[INDEX] 'use PTRA, PTRA -= INDEX*SCALE 1111nnnnn PTRB--[INDEX] 'use PTRB, PTRB -= INDEX*SCALE 1010NNNNN ++PTRA[INDEX] 'use PTRA + INDEX*SCALE, PTRA += INDEX*SCALE 1110NNNNN ++PTRB[INDEX] 'use PTRB + INDEX*SCALE, PTRB += INDEX*SCALE 1010nnnnn --PTRA[INDEX] 'use PTRA - INDEX*SCALE, PTRA -= INDEX*SCALE 1110nnnnn --PTRB[INDEX] 'use PTRB - INDEX*SCALE, PTRB -= INDEX*SCALE
Test number 174 rdbyte x, --ptra [ 1] Error, synthesis != PNut, syn = $fb06575f PNut says = $fb06577fThe difference, starting from bit 0, is at bit 5.
According to the penultimate line in the table above, bit 5 for a --ptra[n] should be 0. Which to me looks like a PNut error / problem / oversight / typo.
rdbyte x, --ptrb[ n ] exhibits the same difference in encoding and I flag it as an error.
Thank you for verifying this for / with me.
Comments
Edit:
It looks like you are generating PTRA-- in your version:
% 1_0111_1111 = $17F
Edit edit: OOPS! Sorry. Was reading your output backwards. You are correct. I suspect that the "P" field is being inverted.
RDBYTE 0,--ptra[1] --> $FB04015F
RDBYTE 0,ptra--[1] --> $FB04017F
That looks correct.
I don't know how you could be getting bit 5 set on a pre-dec/inc operation.
Silly me moved a line of code to the wrong place at some point. I was OR-ing in the always 1 bit in the S register for the pointers *after* I OR-ed the S register to the instruction base.
I have now fixed that little problem and all my synthesised binary codes match PNut's.
So yes, the title is appropriate, "78rpm error likely"! Sorry about the panic.
Thank you for your effort, I have fixed that error of *mine*.
I try and laugh at myself and then move on