can these have a granularity formula ? - and mins and inc sizes for ?
Are all multi-task compatible ?
I see this caveat PASSCNT This is intended as a non-pipeline-stalling alternative to WAITCNT, for use in multi-task programs.
I do not quite follow the * 1 clock if task uses no more than every 4th time slot (4 clocks in single-task)
something like : This takes X cycles + V*S*Tcy more, where Tcy is the sysClk period, S is the Slice multiplier and V is the variable time
0..RealTime. ?
PASSCNT takes 1 clock + as many clocks as there are instructions in the pipeline which belong to the same task as PASSCNT, which will need to be cancelled to support the branch. If no branch occurs, the instruction takes just 1 clock. I will clarify this later tonight when I make some more changes. Sorry about the ambiguity.
Just to clarify, R must be 1 for these instructions SUBR, CMPSUB, INCMOD and DECMOD ? (iF 0 they do not decode correctly)
R may be 0, but then the result won't get stored. These are all set up as R=1 by default, but you could do an "nr" after the operands to stop D from being written.
R may be 0, but then the result won't get stored. These are all set up as R=1 by default, but you could do an "nr" after the operands to stop D from being written.
Chip: Then how do you decode these instructions with R=0 as in my post above?
eg
[TABLE="class: cms_table, width: 1059"]
[TR]
[TD]111000[/TD]
[TD]0[/TD]
[TD]0[/TD]
[TD]0[/TD]
[TD]0[/TD]
[TD]1111[/TD]
[TD]DDDDDDDDD[/TD]
[TD]SSSSSSSSS[/TD]
[TD]SETINDS[/TD]
[TD]D,S[/TD]
[TD]Inc/Dec INDA by S and INDB by D (-256..+255) lower/higher=$000/$1FF[/TD]
[/TR]
[TR]
[TD]111000[/TD]
[TD]Z[/TD]
[TD]C[/TD]
[TD]R[/TD]
[TD]I[/TD]
[TD]CCCC[/TD]
[TD]DDDDDDDDD[/TD]
[TD]SSSSSSSSS[/TD]
[TD]SUBR[/TD]
[TD]D,[#]S[/TD]
[TD]Subtract (reverse) D=S-D[/TD]
[/TR]
[/TABLE]
Chip: I also presume that the instructions in opcode 000011 that do not have an operand (CACHEX, SYNCTRx, etc) have R=0 ?
That's right. For many instructions Z, C, and R make no sense, but in the master list I posted, if they are shown, it means they are flexible in hardware. When I document the instruction set, though, I'll show them as the assembler in PNUT.EXE assembles them, which is with those bits cleared.
The reason the master list shows them as flexible is because it comes from the Verilog source. So, those are more or less notes to myself. In practice, many of those bits will be inflexibly cleared to 0.
That's right. For many instructions Z, C, and R make no sense, but in the master list I posted, if they are shown, it means they are flexible in hardware. When I document the instruction set, though, I'll show them as the assembler in PNUT.EXE assembles them, which is with those bits cleared.
The reason the master list shows them as flexible is because it comes from the Verilog source. So, those are more or less notes to myself. In practice, many of those bits will be inflexibly cleared to 0.
Thanks Chip. I will add them as 0 in the spreadsheet summary. This way, they could be used as a 1 for a different instruction later. As you know, it is quite common for micros to have undocumented 'features' for unused codes.
Have you had time to check my posts #180 & #187? I am quite concerned about the possibility of a decoding bug.
Thanks Chip. I will add them as 0 in the spreadsheet summary. This way, they could be used as a 1 for a different instruction later. As you know, it is quite common for micros to have undocumented 'features' for unused codes.
Have you had time to check my posts #180 & #187? I am quite concerned about the possibility of a decoding bug.
Don't worry. There's no decoding problem. There's just some problem with the doc's you've got. I'll look into this pretty soon...
Here is the latest instruction summary spreadsheet zipped
Look in post #151 for my own list. That will clear up things, I think. Also, JP/JNP/JPD/JNPD use the D register contents to point to a single pin 0..127, instead of acting as a mask, like the spreadsheet shows.
Tomorrow I hope to get more documentation done.
Maybe I should break from all the complicated stuff and just document the obvious instructions for a while.
Look in post #151 for my own list. That will clear up things, I think. Also, JP/JNP/JPD/JNPD use the D register contents to point to a single pin 0..127, instead of acting as a mask, like the spreadsheet shows.
Tomorrow I hope to get more documentation done.
Maybe I should break from all the complicated stuff and just document the obvious instructions for a while.
Thanks for putting this document together. : ]
I'm going to start making it my night time reading material until the official documentation is released.
Look in post #151 for my own list. That will clear up things, I think. Also, JP/JNP/JPD/JNPD use the D register contents to point to a single pin 0..127, instead of acting as a mask, like the spreadsheet shows.
Tomorrow I hope to get more documentation done.
Maybe I should break from all the complicated stuff and just document the obvious instructions for a while.
Thanks Chip.
I have updated JP etc. I see that the SETP etc use D in the same way (pin 0..127). Additionally SETP etc can use #n.
This is different to the WAITPxx where the PORTA is used with a bit mask [#]S.
Yes, perhaps getting the obvious ones done might be worthwhile. It will give your brain a break, and we all can get those easy ones out of the way in the docs.
Should you have to redo the logic, I can see a couple of ways to slightly modify the decoding that would perhaps increase the P2 functionality. Just PM me if this happens - it is nothing complicated.
BTW I have realised (just had a senior moment here) the subtle differences between CMPS / SUBS and CMPSX / SUBSX and their C flag results.
Here is the latest spreadsheet, updated with Chip's post #181. There were quite a number of bit changes to the zcri flags.
All the lines in light blue have been verified to this post. Lines in pink (and other colors) are because there is something unverified or I don't understand something to summarize properly.
We need to make changes the "Starting four tasks" example.
The current example is showing normal jumps where it should be using JMPTASK.
current:
JMP #task0 'task 0 begins here when the cog starts (this JMP takes 4 clocks)
JMP #task1 'task 1 begins here after task 0 executes SETTASK (this JMP takes 1 clock)
JMP #task2 'task 2 begins here after task 0 executes SETTASK (this JMP takes 1 clock)
JMP #task3 'task 3 begins here after task 0 executes SETTASK (this JMP takes 1 clock)
suggested:
JMPTASK #task1,#%0010 'task 1 begins here after task 0 executes SETTASK (%0010 = Set PC1)
JMPTASK #task2,#%0100 'task 2 begins here after task 0 executes SETTASK (%0010 = Set PC2)
JMPTASK #task3,#%1000 'task 3 begins here after task 0 executes SETTASK (%0010 = Set PC3)
We don't need a JMPTASK for PC0 (task 0) because PC0 is already at the correct location after executing the JMPTASK for task3.
It might be a good idea to point out the use of the quaternary (%%) prefix used by SETTASK, I initial thought that was a typo.
Thanks,
C.W.
Note to Chip: Chip, this multiitasking is ssswwweeeeetttttttt.
I've rewritten the "PIPELINE" section of my docs to give a blanket definition of self-modifying-code timing and branch timing. I didn't get any new instruction-level doc's done, but I tried to explain the pipeline so that people can understand its timing and apply it to any case, on their own:
I'd like to recommend that the instruction bit patterns be removed from the main document and limited to the reference document. I think this will make the main document easier to read and will also help to avoid consistency errors.
I'd like to recommend that the instruction bit patterns be removed from the main document and limited to the reference document. I think this will make the main document easier to read and will also help to avoid consistency errors.
I think now that we have a separate detailed assembler reference section that we could just drop this column and yes, it is bound to be inconsistent and certainly just creates extra work trying to maintain it. I will remove those columns in the main document then.
I noticed that the multitasking section list REPS/REPD as NOT supporting multitasking, however the REPS/REPD section give a multitasking example.
I see in the latest copy of Chip's txt file that REPS/REPD are no longer listed as not supporting multitasking, so I assume the example showing them supporting mutlitasking is correct and we can remove REPS/REPD from the list of excluded instructions for multitasking.
There are some restrictions using the REPD/S instructions with multitasking because there is only 1 internal register used for the REPx instructions.
However, the most simple use of multitasking per cog is using up to 4 tasks where each task is interleaved. This is performed by hardware. There are other possibilities too.
Don't forget, it is possible to run multitasking one each and every cog!
I'm still running up against the limitations of Google Docs. While looking around for a solution to the performance issues, I came across Google Cloud Connect (https://tools.google.com/dlpage/cloudconnect). Anyone here familiar with it? It seems to provide google drive/docs integration for MS Office documents and enables some level of collaboration in the process. And it looks like the word documents are still sharable for those who only want/need read-only access.
Comments
Yes, as a default, R=1 for those instructions.
PASSCNT takes 1 clock + as many clocks as there are instructions in the pipeline which belong to the same task as PASSCNT, which will need to be cancelled to support the branch. If no branch occurs, the instruction takes just 1 clock. I will clarify this later tonight when I make some more changes. Sorry about the ambiguity.
R may be 0, but then the result won't get stored. These are all set up as R=1 by default, but you could do an "nr" after the operands to stop D from being written.
eg
That's right. For many instructions Z, C, and R make no sense, but in the master list I posted, if they are shown, it means they are flexible in hardware. When I document the instruction set, though, I'll show them as the assembler in PNUT.EXE assembles them, which is with those bits cleared.
The reason the master list shows them as flexible is because it comes from the Verilog source. So, those are more or less notes to myself. In practice, many of those bits will be inflexibly cleared to 0.
Have you had time to check my posts #180 & #187? I am quite concerned about the possibility of a decoding bug.
Don't worry. There's no decoding problem. There's just some problem with the doc's you've got. I'll look into this pretty soon...
Much of that come from.
Propeller2DetailedPreliminaryFeatureList-v2.pdf
Here is the latest instruction summary spreadsheet zipped
P2_Instructions(12).zip
After reformatting of my PC -- I don't have any program to show Yours files
Look in post #151 for my own list. That will clear up things, I think. Also, JP/JNP/JPD/JNPD use the D register contents to point to a single pin 0..127, instead of acting as a mask, like the spreadsheet shows.
Tomorrow I hope to get more documentation done.
Maybe I should break from all the complicated stuff and just document the obvious instructions for a while.
I post my file I generate my PDF's from.
Maybe that will be simpler to You to edit in it what are incorect.
Corrected.
I see PropTool garbled little it.
Will repost edited in some time
pdf is obsolete and removed.
I'm going to start making it my night time reading material until the official documentation is released.
I have updated JP etc. I see that the SETP etc use D in the same way (pin 0..127). Additionally SETP etc can use #n.
This is different to the WAITPxx where the PORTA is used with a bit mask [#]S.
Yes, perhaps getting the obvious ones done might be worthwhile. It will give your brain a break, and we all can get those easy ones out of the way in the docs.
Should you have to redo the logic, I can see a couple of ways to slightly modify the decoding that would perhaps increase the P2 functionality. Just PM me if this happens - it is nothing complicated.
BTW I have realised (just had a senior moment here) the subtle differences between CMPS / SUBS and CMPSX / SUBSX and their C flag results.
All the lines in light blue have been verified to this post. Lines in pink (and other colors) are because there is something unverified or I don't understand something to summarize properly.
Once again, I have zipped the spreadsheet.
P2_Instructions(13).zip
Any new info updates?
The current example is showing normal jumps where it should be using JMPTASK.
current:
JMP #task0 'task 0 begins here when the cog starts (this JMP takes 4 clocks)
JMP #task1 'task 1 begins here after task 0 executes SETTASK (this JMP takes 1 clock)
JMP #task2 'task 2 begins here after task 0 executes SETTASK (this JMP takes 1 clock)
JMP #task3 'task 3 begins here after task 0 executes SETTASK (this JMP takes 1 clock)
suggested:
JMPTASK #task1,#%0010 'task 1 begins here after task 0 executes SETTASK (%0010 = Set PC1)
JMPTASK #task2,#%0100 'task 2 begins here after task 0 executes SETTASK (%0010 = Set PC2)
JMPTASK #task3,#%1000 'task 3 begins here after task 0 executes SETTASK (%0010 = Set PC3)
We don't need a JMPTASK for PC0 (task 0) because PC0 is already at the correct location after executing the JMPTASK for task3.
It might be a good idea to point out the use of the quaternary (%%) prefix used by SETTASK, I initial thought that was a typo.
Thanks,
C.W.
Note to Chip: Chip, this multiitasking is ssswwweeeeetttttttt.
Prop2_Docs.txt
I think now that we have a separate detailed assembler reference section that we could just drop this column and yes, it is bound to be inconsistent and certainly just creates extra work trying to maintain it. I will remove those columns in the main document then.
BTW, good to see you back on board!
pdf is obsolete and removed.
I see in the latest copy of Chip's txt file that REPS/REPD are no longer listed as not supporting multitasking, so I assume the example showing them supporting mutlitasking is correct and we can remove REPS/REPD from the list of excluded instructions for multitasking.
Can Chip verify this?
Thanks,
C.W.
I like how simple it is too. yet powerful. I can already think of a few uses for it.
I was total unaware of any kind of hardware multitasking support on a single COG.
Great work!
However, the most simple use of multitasking per cog is using up to 4 tasks where each task is interleaved. This is performed by hardware. There are other possibilities too.
Don't forget, it is possible to run multitasking one each and every cog!