@cgracey. Hi Chip, there have been a number of times I've had a look at your document and wanted to leave a comment. Would it be possible for you to change the default permissions so that we can at least leave a comment?
I'm having trouble with the new files and something has changed with PNut's handling of REP but I will try to find out although that information tends to get buried not just in one thread but in who knows which thread what with all the OT stuff.
How does addct1 etc differ from addcnt?
I have this transmit code that PNut complains about and doesn't work:
send setb A,#8 ' add stop bit
shl A,#1 ' insert start bit
getcnt A1
rep @sn1,#10
testb A,#0 wz ' test next bit to send
setbnz outb,#tx_pin ' set/clr txd
addcnt A1,bit_time
waitcnt
shr A,#1
sn1 ret
I captured this at the time of discussion. Same with the other example. The GitBook is kind of awesome, but it does not have tables... Smile. Oh well, there are two in that book and maybe I'll figure something out to do more.
@cgracey. Hi Chip, there have been a number of times I've had a look at your document and wanted to leave a comment. Would it be possible for you to change the default permissions so that we can at least leave a comment?
I'm having trouble with the new files and something has changed with PNut's handling of REP but I will try to find out although that information tends to get buried not just in one thread but in who knows which thread what with all the OT stuff.
How does addct1 etc differ from addcnt?
I have this transmit code that PNut complains about and doesn't work:
send setb A,#8 ' add stop bit
shl A,#1 ' insert start bit
getcnt A1
rep @sn1,#10
testb A,#0 wz ' test next bit to send
setbnz outb,#tx_pin ' set/clr txd
addcnt A1,bit_time
waitcnt
shr A,#1
sn1 ret
Change ADDCNT to ADDCT1 and change WAITCNT to WAITCT1.
You now have ADDCT1..3, not just ADDCNT. Same with WAITCT1..3, instead of just WAITCNT. You've got 3 timers now.
I captured this at the time of discussion. Same with the other example. The GitBook is kind of awesome, but it does not have tables... Smile. Oh well, there are two in that book and maybe I'll figure something out to do more.
I think REP still uses just @symbol for determining the instruction count, not #.
No, it had to be an @ to work and it didn't like local labels either. However the main problem was that I was starting up a receive cog in #10 but the new FPGA now "only" has 10 cogs. Also it seems PNut allows labels anywhere on a line so when it finds old instructions like addcnt it creates a symbol then throws an error on the operand Easy fixed but I got caught for a second. So I use the addct1 etc but why couldn't they just be called addcnt1 etc rather than truncating them unnecessarily?
I can't check at the moment. When we know which it is, I'll make edits. At the time we had the discussion, I'm pretty sure the "#@" syntax was present in a lot of the "bad label" discussion I initiated.
When it was all resolved, and I realized the label argument was stupid, I typed that one up.
No, it had to be an @ to work and it didn't like local labels either. However the main problem was that I was starting up a receive cog in #10 but the new FPGA now "only" has 10 cogs. Also it seems PNut allows labels anywhere on a line so when it finds old instructions like addcnt it creates a symbol then throws an error on the operand Easy fixed but I got caught for a second. So I use the addct1 etc but why couldn't they just be called addcnt1 etc rather than truncating them unnecessarily?
I like ADDCNT1 better, too, but when we have to make WAITxxx, we only have three letters to work with. I was thinking TM1..3 might be better than CT1..3.
I can't check at the moment. When we know which it is, I'll make edits. At the time we had the discussion, I'm pretty sure the "#@" syntax was present in a lot of the "bad label" discussion I initiated.
When it was all resolved, and I realized the label argument was stupid, I typed that one up.
Again, let me know which it is.
I'm not at my computer, but I'm pretty sure it's @label.
I was thinking TM1..3 might be better than CT1..3.
It is a counter being used as a timer, but the guide here should be what units are used ?
The values added and compared are cycle counts, not ns, so Count semantics seems correct.
What does seem natural is to include a simple backward compatible alias
ie when someone codes a default (As above)
addcnt A1,bit_time
waitcnt
that becomes
addct1 A1,bit_time
waitct1
if they need other Counters they code
addct2 A1,bit_time
waitct2
New code using all 3 timers would naturally use 1.2.3
I was thinking TM1..3 might be better than CT1..3.
It is a counter being used as a timer, but the guide here should be what units are used ?
The values added and compared are cycle counts, not ns, so Count semantics seems correct.
What does seem natural is to include a simple backward compatible alias
ie when someone codes a default (As above)
addcnt A1,bit_time
waitcnt
that becomes
addct1 A1,bit_time
waitct1
if they need other Counters they code
addct2 A1,bit_time
waitct2
New code using all 3 timers would naturally use 1.2.3
If we exceed 7 characters, we overshoot what was supposed to be the next tab stop.
I know the P2 is not quite set in cement yet but is it that fluid that we have different machine codes for the same opcodes on minor updates? I used my assembler written in TF2 to test a little cordic function and it kept crashing. Comparing the machine code it produced with what PNut *now* produces shows something is different. Do I have to go through all the opcodes again or is just a few minor things that have changed?
Loopy, all Chip is providing are the binary image files (.rbf, .pof, .jic). They are built for the specific boards and I can't imagine there is any way to port them ot another board. You'd need the actual verilog source so you could take care of pin assignments and such and then rebuild them for the target boards.
Yeah, with all the joy and buzz from Tachyon Forth on the Propeller 2, that just slipped my mind. I was actually looking at the DE0-Nano just to get going when I got this rather mis-guided brainwave.
The DE0-Nano is still available at $89.00USD from Altera.
At least I don't have to study how to hack and modify Verilog;-)
I know the P2 is not quite set in cement yet but is it that fluid that we have different machine codes for the same opcodes on minor updates? I used my assembler written in TF2 to test a little cordic function and it kept crashing. Comparing the machine code it produced with what PNut *now* produces shows something is different. Do I have to go through all the opcodes again or is just a few minor things that have changed?
EDIT: Just did a diff between the old and new and I can spot the changes but a little heads up would be welcome next time
Peter, sorry I didn't say anything. I'll remember next time, maybe putting asterisks on the affected lines in instructions.txt, or something.
This whole matter of opcode assignment has been the most ongoingly-difficult aspect of the whole project. It's something I've wished was sublimated into the design process, like other implementation details, but it's always sticking out.
I know the P2 is not quite set in cement yet but is it that fluid that we have different machine codes for the same opcodes on minor updates? I used my assembler written in TF2 to test a little cordic function and it kept crashing. Comparing the machine code it produced with what PNut *now* produces shows something is different. Do I have to go through all the opcodes again or is just a few minor things that have changed?
Well if I were in your position I wouldn't want to be unnecessarily constricted all because the P2 image was released early for us eager testers. However I was right in the middle of trying to update the document with the new format, update my Tachyon Forth kernel, and my assembler etc while writing a short snippet to test interactively when I had one crash after another. Seems it wasn't a bug in the chip, the bug was Chip!
I can always use a diff tool to spot any changes to the instruction set and hopefully there aren't too many next time, I'm trying to tidy up the P2 assembly instruction set document and I'm having as much success as trying to keep my workbench tidy!
What about just using 'WTxxxxx' instead of 'WAITxxx'?
'WTxxxxx' works, and is probably better than adding a param.
WAITCNT #n is ok,
but to be consistent the other form needs to have #n first
ADDCNT #n, S, D
and then you have 3 params, which is not as easy to read.
It's all these ergonomic matters that take so much time. Implementation can be a lot of work, but waiting for the right ideas to percolate up is the slowest part.
Comments
There is a REP already, and these are Block Move opcodes so maybe
BLKLUT D/#
BLKCOG D/#
For the moment, can you provide the updated SETINTx map? I want to verify the hub rd/wr events.
I just updated that section of the Google Docs document.
Or SETQC/SETQL
Make the most sense to me setting the count and not doing the REP or the BLK with these instructions.
I like SETQC/SETQL. It keeps the SETQx pattern and C, L, etc. is more descriptive than 1, 2, etc.
I'm having trouble with the new files and something has changed with PNut's handling of REP but I will try to find out although that information tends to get buried not just in one thread but in who knows which thread what with all the OT stuff.
How does addct1 etc differ from addcnt?
I have this transmit code that PNut complains about and doesn't work:
Pnut will calculate the value based on the label and plug it in as if you had typed: "rep #4,#10"
https://ddingus.gitbooks.io/propeller-2-instruction-reference/content/rep.html
I captured this at the time of discussion. Same with the other example. The GitBook is kind of awesome, but it does not have tables... Smile. Oh well, there are two in that book and maybe I'll figure something out to do more.
Change ADDCNT to ADDCT1 and change WAITCNT to WAITCT1.
You now have ADDCT1..3, not just ADDCNT. Same with WAITCT1..3, instead of just WAITCNT. You've got 3 timers now.
When it was all resolved, and I realized the label argument was stupid, I typed that one up.
Again, let me know which it is.
I like ADDCNT1 better, too, but when we have to make WAITxxx, we only have three letters to work with. I was thinking TM1..3 might be better than CT1..3.
I'm not at my computer, but I'm pretty sure it's @label.
It is a counter being used as a timer, but the guide here should be what units are used ?
The values added and compared are cycle counts, not ns, so Count semantics seems correct.
What does seem natural is to include a simple backward compatible alias
ie when someone codes a default (As above)
addcnt A1,bit_time
waitcnt
that becomes
addct1 A1,bit_time
waitct1
if they need other Counters they code
addct2 A1,bit_time
waitct2
New code using all 3 timers would naturally use 1.2.3
If we exceed 7 characters, we overshoot what was supposed to be the next tab stop.
what about having the 1-3 be a parameter.
WAITCNT n
ADDCNT S, D, n
That sounds a bit more sensible and it's similar to we do for the CALLD instruction where we specify 1 of 4 registers etc.
new CCCC 1101011 CZ0 000000000 000110001 RET {WC,WZ} CCCC 1101011 CZ0 000000000 000110010 RETA {WC,WZ} CCCC 1101011 CZ0 000000000 000110011 RETB {WC,WZ} old CCCC 1101011 CZ0 000000000 000101101 RET {WC,WZ} CCCC 1101011 CZ0 000000000 000101110 RETA {WC,WZ} CCCC 1101011 CZ0 000000000 000101111 RETB {WC,WZ}EDIT: Just did a diff between the old and new and I can spot the changes but a little heads up would be welcome next time
Yeah, with all the joy and buzz from Tachyon Forth on the Propeller 2, that just slipped my mind. I was actually looking at the DE0-Nano just to get going when I got this rather mis-guided brainwave.
The DE0-Nano is still available at $89.00USD from Altera.
At least I don't have to study how to hack and modify Verilog;-)
Peter, sorry I didn't say anything. I'll remember next time, maybe putting asterisks on the affected lines in instructions.txt, or something.
This whole matter of opcode assignment has been the most ongoingly-difficult aspect of the whole project. It's something I've wished was sublimated into the design process, like other implementation details, but it's always sticking out.
It should probably have a # for consistency.
What about just using 'WTxxxxx' instead of 'WAITxxx'?
Other changes occurred at the end of the D-only instructions, starting at SETEDG.
Thanks for the documentation update.
One question... Are all instructions 2-clock except hub interactions?
They use the same opcode and are differentiated from each other by what are normally the WC and WZ flags.
Everything but hub and WAITxxx instructions are two clocks, if I'm not missing anything.
'WTxxxxx' works, and is probably better than adding a param.
WAITCNT #n is ok,
but to be consistent the other form needs to have #n first
ADDCNT #n, S, D
and then you have 3 params, which is not as easy to read.
It's all these ergonomic matters that take so much time. Implementation can be a lot of work, but waiting for the right ideas to percolate up is the slowest part.
Instead of having the CNT register, and then the three timer registers, CNT1, CNT2 and CNT3
GETCNT, ADDCNT1, ADDCNT2, ADDCNT3 and then WAITCNT1, WAITCNT2, WAITCNT3 and POLLCNT1, POLLCNT2, POLLCNT3 (which all bump into the next tabstop)
You have a system ClockTick register (CT) and the three user Clock Tick registers CT1, CT2 and CT3 and your instructions are all nice again:
GETCT (get clock ticks)
ADDCT1, ADDCT2, ADDCT3 - add S/# to D (and store result in CT1/2/3)
WAITCT1, WAITCT2, WAITCT3
POLLCT1, POLLCT2, POLLCT3
CNT just ceases to be.
Cool. Weren't all the branch instructions four clocks? I must have missed a change somewhere.