This may be obvious but I guess you need to put the same conditional prefix on ALTx and AUGx instructions as well as the instruction they follow. Does it work to put a conditional just on AUGx or ALTx but not on the modified instruction? Does that prevent the modification?
This may be obvious but I guess you need to put the same conditional prefix on ALTx and AUGx instructions as well as the instruction they follow. Does it work to put a conditional just on AUGx or ALTx but not on the modified instruction? Does that prevent the modification?
AUGx is automatically generated by Pnut when needed.
For example
This may be obvious but I guess you need to put the same conditional prefix on ALTx and AUGx instructions as well as the instruction they follow. Does it work to put a conditional just on AUGx or ALTx but not on the modified instruction? Does that prevent the modification?
AUGx is automatically generated by Pnut when needed.
For example
Latest v17 FPGA files and doc's are posted at the top of this thread.
Improved PRNG, now Xoroshiro128+.
New _RET_ instruction prefix for automatic RETurn.
New SKIP/SKIPF instructions for instruction skipping.
New EXECF instruction for branching plus fast skipping in cog memory.
There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.
There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.
There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.
So the problem is PNut, and you can manually craft a correct CALLD > $400 ? (FPGA is ok ?)
The example is a bit long, but the problem shows up when calling the _clock routine. I added a "long 0[207+5]" statement to shift the position of _clock relative to the calling points at _CALL1 and _CALL2. If I insert less than 207 longs it uses the short version of CALLD, and it works OK. If I insert 207 or more longs it will use the long version of CALLD, and fails. Oddly enough, values of 207, 211, 215, etc. kind of work because the zeroes I'm inserting act as NOPs. values of 208, 209, 210, 212, etc. will fail.
EDIT: The _clock routine is located at the end of the file.
There seems to be a problem with CALLD in the latest version. If I do "calld pa,#target" my program crashes if target is more than $400 bytes from the calling location. The PNut assembler uses the version of CALLD with the larger address range, but it shifts the address offset down by 2 bits. If target is less than $400 bytes from the calling location the assembler will use the other version of CALLD, and it works OK.
I see the problem. It's in PNut.exe. I'll get this fixed.
When the assembler sees the two LSBs of the relative address being %00, it errantly applies the ">>2" rule for the short CALLD version.
This example works, but if you get rid of the "+1", it fails:
Comments
Proptool & OpenSpin have the same limit. It's in the x86 compiler code.
It could be made to work like that, but isn't what we already have better?
Is the bus between hub and cog one bidirectional pipe or two unidirectional pipes?
If it were two, seems you could make it read and write hub address at same time, right?
Just wondering...
ALTR is for redirecting cog registers not hub.
For example
For example
If manually coded with a conditional on the AUGx/ALTx instruction its the same as any other instruction and is only executed if the condition is true.
If the P2 buss is anything like the P1, then it's half-duplex.
Improved PRNG, now Xoroshiro128+.
New _RET_ instruction prefix for automatic RETurn.
New SKIP/SKIPF instructions for instruction skipping.
New EXECF instruction for branching plus fast skipping in cog memory.
Thanks a lot for checking them all out.
You can try out _ret_ now. I'm looking forward to getting back on the interpreter tomorrow.
Another change to the docs.
NOP is no longer an alias for "IF_0000 ROR 0,0" and now has its own opcode $00000000 = NOP
Okay. I changed that in the spreadsheet, but I haven'tlooked in the doc's, yet.
The only changes were that RET/RETA/RETB (I=1) were folded into the CALL/CALLA/CALLB encodings (I = 0), which made room for SKIP/SKIPF/EXECF.
The spreadsheet has been updated, but its layout is still the same.
Dave, can you please post the example?
So the problem is PNut, and you can manually craft a correct CALLD > $400 ? (FPGA is ok ?)
EDIT: The _clock routine is located at the end of the file.
I see the problem. It's in PNut.exe. I'll get this fixed.
When the assembler sees the two LSBs of the relative address being %00, it errantly applies the ">>2" rule for the short CALLD version.
This example works, but if you get rid of the "+1", it fails:
Try this v17b of PNut.exe:
https://drive.google.com/file/d/0B9NbgkdrupkHRE80d1lqRnd2NkE/view?usp=sharing
http://forums.parallax.com/discussion/166147/ozpropdev-or-cluso99-what-s-that-pnut-assembler-addressing-problem-again
Did you mean that the code in this post still fails ?
http://forums.parallax.com/discussion/comment/1401185/#Comment_1401185
or did you mean the issue above, is not fixed ?