I compared the documentation spreadsheet with the file called "instructions_v16.txt" inside the zip file.
There is one less instruction (JEVENT) and four MNEMONIC differences between "instructions_v16.txt" and spreadsheet (XLS):
TXT, XLS
--- ---
ANDF, AND
ORF, OR
XORF, XOR
NOTF, NOT
JEVENT (missing)
Are the scripts developed by Chip and Seairth still available for this task?
Currently how opcode testing is being done?
I realized the JEVENT instruction wasn't going to work because the hardware used the D-field instruction bits, not the D-value bits, so I took it out.
Fortunately, PNut.exe uses AND/OR/XOR/NOT. It's just the instructions_v16.txt that is wrong. You can get rid of those four "F"s in that file. Sorry about this.
I just updated the top post in this thread with v16a, which added 'NOT D' to PNut.exe and fixed typos in instructions.txt, where ANDF/ORF/XORF/NOTF were wrongly listed for AND/OR/XOR/NOT.
I just updated the top post in this thread with v16a...
Can you add separate version numbers for FPGA image (v16, 25 Feb?), Assembler/Tools (v16a,28 Feb?) and Documents (v?) to #1.
That way everyone can see what parts have been updated, and what remains stable.
This must be some kind of pipeline trick, right?
The instruction must already be in the pipeline when this write is made, right?
Right. It modifies the next instruction that is about to get decoded. It just mux's in alternate data for various bitfields from the instruction that is currently executing. It's "pulling a fast one".
Ok. Thanks.
Any hint as to how this "result" thing works inside?
Doesn't this overwrite the bits that define the instruction?
For the purpose of the ALTI instruction redirecting the result register, the "R" field was just "made up". You're right, it uses what would be the instruction bitfield in an instruction long, but the D register serving this purpose is not also an instruction. It's just three 9-bit pointers: R, D, and S.
That's the difference between the SETx and ALTx instructions. SETx's read/modify/write the stored location (D is address) of the instruction in RAM. ALTx's modify (Both operands can be used) the subsequent prefetched instruction in the pipeline. RAM isn't touched.
I like to think of ALTx's as prefixes that just happen to produce an instruction variation rather than a different instruction.
AUGx and SETQx I've been calling prefixes too but they are a little different again in that the instruction they affect doesn't have to be the subsequent one.
Chip,
There is an awful lot of differing SET instructions. I feel a level of clarity could be imposed here.
I guess I'm slow today... Feel like I almost get it, but not quite...
In your doc examples there is this:
ALTR pointer ‘set next write to pointer
XOR INA,INB ‘write INA^INB to register[pointer]
Does this actually overwrite the XOR instruction bitfield?
Would it have to be restored before using it as XOR again?
Usually, the D field of an instruction sets the result register. At the time the instruction gets decoded, though, the result register begins to be tracked separately, allowing an alteration to occur.
SETR inst,op ‘set reg[27:19] to op[8:0]
NOP ‘first spacer instruction, could be anything
NOP ‘second spacer instruction, could be anything
inst MOV x,y ‘operate on x using y, MOV can become AND/OR/XOR/etc.
This makes sense to me, it is changing the type of instruction.
But, the terminology seems strange... I think I'd call this the "I" for Instruction field.
These are mostly the bits called "INSTR" in P1 manual.
Anyway, I think it's a different kind of "result" register from ALTR.
Maybe it's the same under the hood somehow though...
Comments
I went through the same puzzle, have a read of it - http://forums.parallax.com/discussion/comment/1400122/#Comment_1400122
I'm not sure replacing the descriptive "lower" made any diff. I'd grok'd it by that stage anyway.
There is one less instruction (JEVENT) and four MNEMONIC differences between "instructions_v16.txt" and spreadsheet (XLS):
Are the scripts developed by Chip and Seairth still available for this task?
Currently how opcode testing is being done?
I realized the JEVENT instruction wasn't going to work because the hardware used the D-field instruction bits, not the D-value bits, so I took it out.
Fortunately, PNut.exe uses AND/OR/XOR/NOT. It's just the instructions_v16.txt that is wrong. You can get rid of those four "F"s in that file. Sorry about this.
setb --> bith
nob --> bitn
clrb --> bitl
Seems to work with just that change.
Can you add separate version numbers for FPGA image (v16, 25 Feb?), Assembler/Tools (v16a,28 Feb?) and Documents (v?) to #1.
That way everyone can see what parts have been updated, and what remains stable.
Would be nice to have a list of what is not allowed inside the REP loop.
For example, I can't remember if jumps are allowed or not...
Not sure what the "R" in SETR stands for.
But, it looks like these are bits that define the instruction, right?
The R in ALTR must be different as it stands for "result".
That's what I recall.
Conditional execution is allowed, just not an explicit program flow change.
On JMP, REP dies. Program continues.
Pretty sure a JMP can be in there, ignored conditionally, and on condition met, exits REP circuit.
The "R" in "SETR" does stand for "result". It's bits [27:19] which get used for the result field in D, to be employed by ALTI.
Any hint as to how this "result" thing works inside?
Doesn't this overwrite the bits that define the instruction?
The instruction must already be in the pipeline when this write is made, right?
Right. It modifies the next instruction that is about to get decoded. It just mux's in alternate data for various bitfields from the instruction that is currently executing. It's "pulling a fast one".
For the purpose of the ALTI instruction redirecting the result register, the "R" field was just "made up". You're right, it uses what would be the instruction bitfield in an instruction long, but the D register serving this purpose is not also an instruction. It's just three 9-bit pointers: R, D, and S.
In your doc examples there is this:
Does this actually overwrite the XOR instruction bitfield?
Would it have to be restored before using it as XOR again?
AUGx and SETQx I've been calling prefixes too but they are a little different again in that the instruction they affect doesn't have to be the subsequent one.
Chip,
There is an awful lot of differing SET instructions. I feel a level of clarity could be imposed here.
Usually, the D field of an instruction sets the result register. At the time the instruction gets decoded, though, the result register begins to be tracked separately, allowing an alteration to occur.
EDIT: Another wording: The D field of an instruction selects the register to deposit the result in.
Still wondering about "SETR" though. Seems it won't really have anything to do with where the result goes unless it's used with ALTI.
Is SETR intended to be used mainly on an ALTI instruction?
That's about all it's useful for. It initializes a field in a register that ALTI uses as its D operand.
This makes sense to me, it is changing the type of instruction.
But, the terminology seems strange... I think I'd call this the "I" for Instruction field.
These are mostly the bits called "INSTR" in P1 manual.
Anyway, I think it's a different kind of "result" register from ALTR.
Maybe it's the same under the hood somehow though...
No.
But, just like the limit max in P1, I think they are backwards...
Guess I'm used to C++ where if I do max(3,5), I'd get 5 back.
In P2, if you do MAX with D=3 and S=5, D stays 3.
If I'm seeing it right, anyway.
Source is value to be operated on.
In C/C++, MAX can be seen as follows:
That "feels" backwards.