Is there a specific reason that cog-reg addressing not exists for SETINDA and SETINDB ?
There seem to be only immediate versions. Setting the inda/b to a calculated address would be very handy for lookup tables and such.
I can do it with Prop1 style instruction modifing with movs (and movd for indb), but that takes always 4 cycles.
In the short period I program the Prop2 I've ran several times into this because for PTRA/B and SPA/B this is possible.
Is there a specific reason that cog-reg addressing not exists for SETINDA and SETINDB ?
There seem to be only immediate versions. Setting the inda/b to a calculated address would be very handy for lookup tables and such.
I can do it with Prop1 style instruction modifing with movs (and movd for indb), but that takes always 4 cycles.
In the short period I program the Prop2 I've ran several times into this because for PTRA/B and SPA/B this is possible.
Andy
The problem is that INDA/INDB get written early in stage 2 of the pipeline, not in stage 4 when D and S register contents are available. Only the opcode bits are available in stage 2.
yes. Since I used other assembler before, I was stumbeling about this more then one time.
Most time I get bitten by the # is NOT using it on branches and jumping to the content of the adress not the adress itself.
After a while I got used to it. As allways the propeller is diferent because somehow Chip does not like to be bound by conventions. Just because things are done one way by a lot of people, is not a reason for him to do it that way.
And that is one reason why the P1 (and the P2) are so wonderful and faszinating.
Just think about the P2 Monitor. Remember all those people arguing against it and for boot from SD-card or RAM instead?
And now I read everywhere - yes the Monitor is useful.
Is there a specific reason that cog-reg addressing not exists for SETINDA and SETINDB ?
There seem to be only immediate versions. Setting the inda/b to a calculated address would be very handy for lookup tables and such.
I can do it with Prop1 style instruction modifing with movs (and movd for indb), but that takes always 4 cycles.
In the short period I program the Prop2 I've ran several times into this because for PTRA/B and SPA/B this is possible.
Andy
You could still calculate a value to go into INDA/B. just use a MOVS (or is it MOVD?) into the SETINDA/B instruction. It requires an extra instruction and some delay slots, but it would work I believe.
Can You say if I'm are missing anything in that diagram.
_____________________________________
xxxxxx xxx x xxxx DDDDDDDDD SSSSSSSSS
| | | | | S Source field in instruction (9-bit address = 512 longs)
| | | | D Destination field in instruction (9-bit address = 512 longs)
| | | CCCC Condition/INDx-AABB code field
| | I Immediate effect bit 0 = SSSSSSSSS register 1 = #SSSSSSSSS immediate, zero-extended
| ZCR flags --- Z = Zero effect, C = Carry effect, R = Register effect
Opcode base field
Many of the new Prop2 instructions use the D- and S-field not in its originally sense.
In case of PUSH the D field holds a source register or value.
On Prop1 we had that also with RDBYTE and WRBYTE, where WRBYTE uses the D-field for a source.
Things like this where P1 to P2 behavior (either in the assembler or in the chip itself) need to be collected together in the documentation and also highlighted in each instruction description. P1 PASM programmers will trip over these differences and they'll generate a lot of traffic and confusion. Better to answer the question before it is asked.
Because of the index registers, the D and S fields at times might be more clearly referred to as Ra and Rb (I didn't want to use Rx and Ry) to just denote generic COG registers (memory locations).
Just something to consider for the documentation team.
*as always, my comments should be reviewed by someone that actually knows something!
...Can you say me what you expect what each of these 2 instructions will do? :
1) POPA reg17
2) POPA #reg17
compare to jmpret/call
call to #label jumps to adress/register named label
call to label jumps to adress of the content of adress/register named label
so indeed a
popa #label could save the value in the adress/register named label and a
popa label could save the value in the adress of the content of the adress/register named label.
I was thinking a while about the inconsistency Sapieha was talking about. And somehow he is right.
compare to jmpret/call
call to #label jumps to adress/register named label
call to label jumps to adress of the content of adress/register named label
so indeed a
popa #label could save the value in the adress/register named label and a
popa label could save the value in the adress of the content of the adress/register named label.
mindboggeling, isn't it?
Enjoy!
Mike
Yes, if you compare it with jmp / call. But thats only because jmp and call are inconsistent to all the others.
You need do think of "move to program counter" for jump and call, then it makes sense:
Actually you set a pointer (the pc) and use then the content of the pointer. This indirect use shifts immediate to direct addressing and direct to indirect addressing. Other Assemblers, for other CPUs use often a syntax with parenthesis:
jump DirectAddress
jump (indirectAddr)
Is there a specific reason that cog-reg addressing not exists for SETINDA and SETINDB ?
There seem to be only immediate versions. Setting the inda/b to a calculated address would be very handy for lookup tables and such.
I can do it with Prop1 style instruction modifing with movs (and movd for indb), but that takes always 4 cycles.
In the short period I program the Prop2 I've ran several times into this because for PTRA/B and SPA/B this is possible.
Andy
You could still calculate a value to go into INDA/B. just use a MOVS (or is it MOVD?) into the SETINDA/B instruction. It requires an extra instruction and some delay slots, but it would work I believe.
It is MOVS for INDA and MOVD for INDB and I do that already. But it's not really elegant.
A lookup table read would look like that, if the instruction would exist:
For sure if you use the inda register more than 1 time with postincrement or so, then setting the inda first makes sense.
The Prop2 needs 2 delay slots between modifing an instruction and execute it, while the Prop1 needs only one. This can be a difficult to find trap, if you port code from Prop1 to Prop2, because the code compiles fine and works also, just with the unmodified value. (I had to learn this already).
I think we could make the compiler/assembler detect this and throw a warning out when you don't have two instructions between a modifying instruction and it's target.
My own adventures so far include dropping the NOP instructions in there on first pass, then once things are working, back fill with whatever makes sense to put out of order, similar to how many of us do it on P1.
I think we could make the compiler/assembler detect this and throw a warning out when you don't have two instructions between a modifying instruction and it's target.
I think multi-tasking changes that doesn't it, in that the cycles used by other threads count towards the delay?
Can You say if I'm are missing anything in that diagram.
_____________________________________
xxxxxx xxx x xxxx DDDDDDDDD SSSSSSSSS
| | | | | S Source field in instruction (9-bit address = 512 longs)
| | | | D Destination field in instruction (9-bit address = 512 longs)
| | | CCCC Condition/INDx-AABB code field
| | I Immediate effect bit 0 = SSSSSSSSS register 1 = #SSSSSSSSS immediate, zero-extended
| ZCR flags --- Z = Zero effect, C = Carry effect, R = Register effect
Opcode base field
That's the master opcode scheme. There are some exceptions, though.
popa #label could save the value in the adress/register named label and a
popa label could save the value in the adress of the content of the adress/register named label.
mindboggeling, isn't it?
Enjoy!
Mike
It doesn't work like that. POPA can only have a register expressed, not a constant. The register (D) will receive the result of the pop. D could be INDA or INDB ($1F6 or $1F7).
It doesn't work like that. POPA can only have a register expressed, not a constant. The register (D) will receive the result of the pop. D could be INDA or INDB ($1F6 or $1F7).
ADD $1F6 +xx or $1F7 +xx. th have it work as indexed vector
No. And if you want to use INDA or INDB, use the names INDA or INDB, instead of the locations $1F6 or $1F7, so that the assembler will be able to handle things properly.
No. And if you want to use INDA or INDB, use the names INDA or INDB, instead of the locations $1F6 or $1F7, so that the assembler will be able to handle things properly.
Is there a specific reason that cog-reg addressing not exists for SETINDA and SETINDB ?
There seem to be only immediate versions. Setting the inda/b to a calculated address would be very handy for lookup tables and such.
I can do it with Prop1 style instruction modifing with movs (and movd for indb), but that takes always 4 cycles.
In the short period I program the Prop2 I've ran several times into this because for PTRA/B and SPA/B this is possible.
Andy
The problem is that INDA/INDB get written early in stage 2 of the pipeline, not in stage 4 when D and S register contents are available. Only the opcode bits are available in stage 2.
Chip thank's for the explanation.
The INDx registers are still incredible useful, especially with the top and bottom wrap around.
All the new features in Prop2 makes Assembly programming much more comfortable, and spares a lot of code size.
Comments
Thanks.
Now I think I understand difference. And in same time inconsistency in some descriptions
So
PUSHA #(0-511)
POPA 0 ---- will make COG register 0 = (0-511)
allmost.
POPA 0 will do whatg you want.
there is no #
you can not POP to a constant.
PUSHA, #FFFF will not work constant is max #FFF
PUSHA 0 uses register 0
PUSHA #0 uses value not register (constant) 0-512
POPA 0 uses register 0
POPA #0 is not possible
you can not POP something into a constant (where should it go?)
Enjoy!
Mike
In my thinking --- I don't think it was constant.
BUT direct Register address (Specified by real number) --- in both instructions as in most assemblers #-stands for number
Is there a specific reason that cog-reg addressing not exists for SETINDA and SETINDB ?
There seem to be only immediate versions. Setting the inda/b to a calculated address would be very handy for lookup tables and such.
I can do it with Prop1 style instruction modifing with movs (and movd for indb), but that takes always 4 cycles.
In the short period I program the Prop2 I've ran several times into this because for PTRA/B and SPA/B this is possible.
Andy
The problem is that INDA/INDB get written early in stage 2 of the pipeline, not in stage 4 when D and S register contents are available. Only the opcode bits are available in stage 2.
yes. Since I used other assembler before, I was stumbeling about this more then one time.
Most time I get bitten by the # is NOT using it on branches and jumping to the content of the adress not the adress itself.
After a while I got used to it. As allways the propeller is diferent because somehow Chip does not like to be bound by conventions. Just because things are done one way by a lot of people, is not a reason for him to do it that way.
And that is one reason why the P1 (and the P2) are so wonderful and faszinating.
Just think about the P2 Monitor. Remember all those people arguing against it and for boot from SD-card or RAM instead?
And now I read everywhere - yes the Monitor is useful.
Enjoy!
Mike
You could still calculate a value to go into INDA/B. just use a MOVS (or is it MOVD?) into the SETINDA/B instruction. It requires an extra instruction and some delay slots, but it would work I believe.
Can You say if I'm are missing anything in that diagram.
Things like this where P1 to P2 behavior (either in the assembler or in the chip itself) need to be collected together in the documentation and also highlighted in each instruction description. P1 PASM programmers will trip over these differences and they'll generate a lot of traffic and confusion. Better to answer the question before it is asked.
Because of the index registers, the D and S fields at times might be more clearly referred to as Ra and Rb (I didn't want to use Rx and Ry) to just denote generic COG registers (memory locations).
Just something to consider for the documentation team.
*as always, my comments should be reviewed by someone that actually knows something!
I was thinking a while about the inconsistency Sapieha was talking about. And somehow he is right.
compare to jmpret/call
call to #label jumps to adress/register named label
call to label jumps to adress of the content of adress/register named label
so indeed a
popa #label could save the value in the adress/register named label and a
popa label could save the value in the adress of the content of the adress/register named label.
mindboggeling, isn't it?
Enjoy!
Mike
Pop to immediate makes no sense, unless we some how would want the instruction immediate value changed...
For me most important was how I shall describe it
Yes, if you compare it with jmp / call. But thats only because jmp and call are inconsistent to all the others.
You need do think of "move to program counter" for jump and call, then it makes sense: Actually you set a pointer (the pc) and use then the content of the pointer. This indirect use shifts immediate to direct addressing and direct to indirect addressing. Other Assemblers, for other CPUs use often a syntax with parenthesis:
jump DirectAddress
jump (indirectAddr)
Andy
It is MOVS for INDA and MOVD for INDB and I do that already. But it's not really elegant.
A lookup table read would look like that, if the instruction would exist: Now I need to do it so:
add index,#table movs set,index nop nop set setinda #0-0 mov value,indaIn this case it makes no sense to use the inda register because with self modifying code you can also do it like on Prop1:add index,#table movs :rd,index nop nop :rd mov value,0-0For sure if you use the inda register more than 1 time with postincrement or so, then setting the inda first makes sense.The Prop2 needs 2 delay slots between modifing an instruction and execute it, while the Prop1 needs only one. This can be a difficult to find trap, if you port code from Prop1 to Prop2, because the code compiles fine and works also, just with the unmodified value. (I had to learn this already).
Andy
My own adventures so far include dropping the NOP instructions in there on first pass, then once things are working, back fill with whatever makes sense to put out of order, similar to how many of us do it on P1.
I think multi-tasking changes that doesn't it, in that the cycles used by other threads count towards the delay?
C.W.
That's the master opcode scheme. There are some exceptions, though.
Thanks
It doesn't work like that. POPA can only have a register expressed, not a constant. The register (D) will receive the result of the pop. D could be INDA or INDB ($1F6 or $1F7).
Can I use.
ADD $1F6 +xx or $1F7 +xx. th have it work as indexed vector
No. And if you want to use INDA or INDB, use the names INDA or INDB, instead of the locations $1F6 or $1F7, so that the assembler will be able to handle things properly.
Thanks
You can add and sub to the INDA/B register but with another syntax: This is all exactly described in Chips "Prop2_Docs.txt" see chapter Indirect Registers
Andy
I saw that -- But notation on it was unclear for me.
Chip thank's for the explanation.
The INDx registers are still incredible useful, especially with the top and bottom wrap around.
All the new features in Prop2 makes Assembly programming much more comfortable, and spares a lot of code size.
Andy
What new?.
S.O:S ambulance screw up theirs work --- So my XMAS was in Hospital
Sorry to hear that Sapieha, I hope all is well now.
Still exploring the P2, working with using the CLUT as a stack now using the new CALLA, RETA, etc.
C.W.
Thanks