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.
EDIT: How about "O" for opcode?
We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
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.
You'll be filling a whole notebook of things to do. Good weather I hope.
We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
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.