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.
Can Chip verify this?
Thanks,
C.W.
In the last Verilog iteration, I made REPS and REPD work with multitasking by having it react only to the task that initiated it. The limitation is that only one task can use it at a time. One thing I overlooked, though, was making JMPTASK kill any REPS/REPD in progress for a task affected by JMPTASK. The remedy is to do a 'REPS #1,#1' before the JMPTASK. This will cause any REPS/REPD in progress to effectively cancel, as executing one instruction once will never causing a jump-back to occur.
The first two bits of the conditions field will be encoded as a modifier for the INDA field. What about the other two bits? Must they be %00 for non-INDx registers, or can they be any value?
The first two bits of the conditions field will be encoded as a modifier for the INDA field. What about the other two bits? Must they be %00 for non-INDx registers, or can they be any value?
They will be ignored, so they can be any value. I changed my doc's to state that. Thanks for asking about this.
Peter,
I'm back at work after a good break. Now, what needs doing?
cheers
Lachlan
I'm kinda back at work again but still need a good break! At the moment we need to take stock of what everyone is doing as everybody seems to be doing their own bits and pieces (I think). This makes it more work to integrate into the online live document but maybe we could add links in the document to these other documents so that bit by bit we can get all this information together in the one place. The assembler reference section has been broken off into it's own document which is being taken care of by Seairth.
Maybe all those who know of changes required to the Google docs can post and let us know.
If I recall correctly, some of the instructions can implicitly make use of the value currently latched in the ALU (e.g. as a timeout for WAITPNE). Since I am unfamiliar with the internal hardware, which instructions modify the ALU value? And is the value latched by the ALU regardless of effects flags?
If I recall correctly, some of the instructions can implicitly make use of the value currently latched in the ALU (e.g. as a timeout for WAITPNE). Since I am unfamiliar with the internal hardware, which instructions modify the ALU value? And is the value latched by the ALU regardless of effects flags?
I just read some material in the Prop2_Docs.txt file that clarifies this. From the WAITPEQ instruction: "the last-written D value becomes a CNTL timeout target, with C returning 0 if the WAITPEQ condition was met, or 1 if the timeout occurred first." Based on the example, I am assuming that the timeout is effectively a CMPCNT. However, precise timing is a little ambiguous here. CMPCNT indicates that C = ! D[31], which would indicate that the the flag would be set (for SUBCNT and CMPCNT) when CNTx is greater than or equal to the test value. (Note: the documentation uses the word "exceeded",)
So, in the following example (assuming single task):
What happens if the pins *are* equal for the first three examples? Does C get set? And does the last example block for one cycle if the pins are not equal?
@Chip
Can't wait for the counter modules documentation!
Thank you for this awesome chip, Chip!
Yes, counters are going to be awesome. I was looking back over some notes from a Nov 2010 Prop2 presentation. I'm looking forward to playing with the hardware Goertzel feature, that will make all sorts of things possible. There were many other automated "background" features that will make them really useful, especially combined with the task switching.
Yes, counters are going to be awesome. I was looking back over some notes from a Nov 2010 Prop2 presentation. I'm looking forward to playing with the hardware Goertzel feature, that will make all sorts of things possible. There were many other automated "background" features that will make them really useful, especially combined with the task switching.
I have fingers crossed for atomic control of external edge time-capture on two timers ....
Here is the latest update to my P2 Instruction Summary (Excel spreadsheet zipped). If you want to print it out, change or remove the darkblue shading (shows updates confirmed to Chips file a few posts back.
Is this thread where Counter Docs will be updated, or is some DOC on a link going to quietly tick-over ?
It's nearly 2 weeks since Chip posted the 'next...' - maybe I've missed it ?
Comments
In the last Verilog iteration, I made REPS and REPD work with multitasking by having it react only to the task that initiated it. The limitation is that only one task can use it at a time. One thing I overlooked, though, was making JMPTASK kill any REPS/REPD in progress for a task affected by JMPTASK. The remedy is to do a 'REPS #1,#1' before the JMPTASK. This will cause any REPS/REPD in progress to effectively cancel, as executing one instruction once will never causing a jump-back to occur.
I'm back at work after a good break. Now, what needs doing?
cheers
Lachlan
pdf is obsolete and removed.
ABS INDA, var
The first two bits of the conditions field will be encoded as a modifier for the INDA field. What about the other two bits? Must they be %00 for non-INDx registers, or can they be any value?
They will be ignored, so they can be any value. I changed my doc's to state that. Thanks for asking about this.
Maybe all those who know of changes required to the Google docs can post and let us know.
Prop2_Docs.txt
Thanks
Incorporated in my PDF
I see one new instruction that we don't have its BIT pattern.
TASKSW, TASKSWD
I hope to finish that part tonight.
TASKSW: $1F8FEDF6
TASKSWD: $5F8FEDF6
Thanks
I just read some material in the Prop2_Docs.txt file that clarifies this. From the WAITPEQ instruction: "the last-written D value becomes a CNTL timeout target, with C returning 0 if the WAITPEQ condition was met, or 1 if the timeout occurred first." Based on the example, I am assuming that the timeout is effectively a CMPCNT. However, precise timing is a little ambiguous here. CMPCNT indicates that C = ! D[31], which would indicate that the the flag would be set (for SUBCNT and CMPCNT) when CNTx is greater than or equal to the test value. (Note: the documentation uses the word "exceeded",)
So, in the following example (assuming single task):
The C flag will be set all three examples. For any larger value of ticks, the flag would not be set. Now, assuming that WAITPEQ works the same way:
What happens if the pins *are* equal for the first three examples? Does C get set? And does the last example block for one cycle if the pins are not equal?
pdf is obsolete and removed.
Prop2_Docs.txt
Next I'll work on the counter documentation.
Thanks
(Prop2_Docs.pdf deleted)
Can't wait for the counter modules documentation!
Thank you for this awesome chip, Chip!
Yes, counters are going to be awesome. I was looking back over some notes from a Nov 2010 Prop2 presentation. I'm looking forward to playing with the hardware Goertzel feature, that will make all sorts of things possible. There were many other automated "background" features that will make them really useful, especially combined with the task switching.
I have fingers crossed for atomic control of external edge time-capture on two timers ....
For the QUAD GETTOPS instruction, I could not find the byte order described.
P2_Instructions(14).zip
The tops bytes of the QUADs get packed into a single long in the order {QUAD3[31..24], QUAD2[31..24], QUAD1[31..24], QUAD0[31..24]}.
What is the purpose of this instruction ? I guess it has to do with graphics.
Andy
Is this thread where Counter Docs will be updated, or is some DOC on a link going to quietly tick-over ?
It's nearly 2 weeks since Chip posted the 'next...' - maybe I've missed it ?
I'll spend today on the counter doc's. It is a pain to describe the counters, but if they don't get documented, they might as well not exist.