It's critical, of course, that this latest version of PNut be used to assemble your programs, so that PTRx expression are assembled correctly.
Wasn't the last proposal for the PTRx encoding backward compatible? It'd be really nice if we didn't have to have separate sets of tools for the P2ES and the next chip .
I implemented what was simplest in logic, because the PTRx computation circuitry was near critical-path and I didn't want to possibly slow things down.
I need to document what the new scheme is, though you can run PNut and see the output for different expressions. There's not a whole lot to it, and I don't know exactly where it breaks compatibility. Need to look at it.
So how was the encoding for PTRx changed? Is this how it turned out?
It's critical, of course, that this latest version of PNut be used to assemble your programs, so that PTRx expression are assembled correctly.
Wasn't the last proposal for the PTRx encoding backward compatible? It'd be really nice if we didn't have to have separate sets of tools for the P2ES and the next chip .
I implemented what was simplest in logic, because the PTRx computation circuitry was near critical-path and I didn't want to possibly slow things down.
I need to document what the new scheme is, though you can run PNut and see the output for different expressions. There's not a whole lot to it, and I don't know exactly where it breaks compatibility. Need to look at it.
So how was the encoding for PTRx changed? Is this how it turned out?
I assembled some code with various PTRx indexes, and the results match the description in my previous post. So the v32 encoding is a subset of the v33 if the P bit is set to the index sign bit when the U bit is zero. Currently, the P2 assemblers set the P bit to zero.
I assembled some code with various PTRx indexes, and the results match the description in my previous post. So the v32 encoding is a subset of the v33 if the P bit is set to the index sign bit when the U bit is zero. Currently, the P2 assemblers set the P bit to zero.
I think you are saying this can be made binary compatible, if the older version assembler is modified slightly, in how it handles unused bits ?
It would be great if binary compatible of P2 & P2+ is possible.
Chip,
Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.
Also note ALTI uses SETR's interpretation rather than ALTR's.
I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.
Chip,
Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.
Also note ALTI uses SETR's interpretation rather than ALTR's.
I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.
EDIT: How about "O" for opcode?
I hear what you are saying, but I think there is more to this. I'm not at my computer now, so I can't look.
It should be SETx where x is a single letter. SETO seems good.
Format of typical instruction:
EEEE OOOOOOO OOI DDDDDDDDD SSSSSSSSS <ins> D,S/#
However I've never really liked EEEE, where presumably E is for Execution. CCCC for Conditions would conflict with C flag bit so that's out. I think opcode[31:28] would be best represented by FFFF for Flags and this would be the smallest change possible both visually and alphabetically.
Format of typical instruction then looks like:
FFFF OOOOOOO OOI DDDDDDDDD SSSSSSSSS <ins> D,S/#
or FOIDS for short:
F for Flags (for conditional execution)
O for Opcode
I for Immediate
D for Destination
S for Source
Comments
Did you see this thread?
http://forums.parallax.com/discussion/169801/augs-not-cancelling-after-a-altd-instruction
Will run some boot tests ASAP.
Thanks, Ozpropdev.
I don't remember and I'm not at home right now where my computer is.
If you run the latest PNut that comes with the new'silicon FPGA files, you can look at the encodings.
Pointer-modifying offsets of -16 to +16 are allowed, while random non-modifying offsets can range from -32 to +31.
My test code is as follows:
dat org 000 00 00 00 00 r0 long 0 001 00 01 04 FB rdlong r0, ptra 002 80 01 04 FB rdlong r0, ptrb 003 00 01 04 FB rdlong r0, ptra[0] 004 01 01 04 FB rdlong r0, ptra[1] 005 0F 01 04 FB rdlong r0, ptra[15] 006 10 01 04 FB rdlong r0, ptra[16] 007 11 01 04 FB rdlong r0, ptra[17] 008 1E 01 04 FB rdlong r0, ptra[30] 009 1F 01 04 FB rdlong r0, ptra[31] 00a 00 01 04 FB rdlong r0, ptra 00b 80 01 04 FB rdlong r0, ptrb 00c 00 01 04 FB rdlong r0, ptra[0] 00d 3F 01 04 FB rdlong r0, ptra[-1] 00e 31 01 04 FB rdlong r0, ptra[-15] 00f 30 01 04 FB rdlong r0, ptra[-16] 010 2F 01 04 FB rdlong r0, ptra[-17] 011 22 01 04 FB rdlong r0, ptra[-30] 012 21 01 04 FB rdlong r0, ptra[-31] 013 20 01 04 FB rdlong r0, ptra[-32] 014 41 01 04 FB rdlong r0, ++ptra 015 C1 01 04 FB rdlong r0, ++ptrb 016 41 01 04 FB rdlong r0, ++ptra[1] 017 4F 01 04 FB rdlong r0, ++ptra[15] 018 40 01 04 FB rdlong r0, ++ptra[16] 019 5F 01 04 FB rdlong r0, --ptra 01a DF 01 04 FB rdlong r0, --ptrb 01b 5F 01 04 FB rdlong r0, --ptra[1] 01c 51 01 04 FB rdlong r0, --ptra[15] 01d 50 01 04 FB rdlong r0, --ptra[16] 01e 7F 01 04 FB rdlong r0, ptra-- 01f FF 01 04 FB rdlong r0, ptrb-- 020 7F 01 04 FB rdlong r0, ptra--[1] 021 71 01 04 FB rdlong r0, ptra--[15] 022 70 01 04 FB rdlong r0, ptra--[16] 023 61 01 04 FB rdlong r0, ptra++ 024 E1 01 04 FB rdlong r0, ptrb++ 025 61 01 04 FB rdlong r0, ptra++[1] 026 6F 01 04 FB rdlong r0, ptra++[15] 027 60 01 04 FB rdlong r0, ptra++[16]I think you are saying this can be made binary compatible, if the older version assembler is modified slightly, in how it handles unused bits ?
It would be great if binary compatible of P2 & P2+ is possible.
Something has niggled at me every time I look at it - The mnemonic naming of SETR vs ALTR. They have entirely different meanings of "R". This doesn't happen with S and D naming. I'd like to see R be reserved for only meaning the Result Register as per ALTR instruction.
Also note ALTI uses SETR's interpretation rather than ALTR's.
I'd like to choose a different letter for bitfield [27:19] uses. Conveniently, SETR is the only mnemonic name that would change in assemblers. The rest is all documentation.
EDIT: How about "O" for opcode?
I hear what you are saying, but I think there is more to this. I'm not at my computer now, so I can't look.
What should we call it, if not SETR?
EDIT: Regarding ALTI, it's correctly labelled as is. I was confused with ALTI's working D register field allotments vs its prefixing actions.
EDIT2: PS: The reason I dug this up now is because I bumped into it while scouring the forum for your post with the floor-plan of the revC change.
It should be SETx where x is a single letter. SETO seems good.
Format of typical instruction: However I've never really liked EEEE, where presumably E is for Execution. CCCC for Conditions would conflict with C flag bit so that's out. I think opcode[31:28] would be best represented by FFFF for Flags and this would be the smallest change possible both visually and alphabetically.
Format of typical instruction then looks like: or FOIDS for short:
F for Flags (for conditional execution)
O for Opcode
I for Immediate
D for Destination
S for Source
Hijack foul! = Great idea! ?
May no aspect be unconsidered, gotta love this forum