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:
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.