Anytime you do a mov phsa, #3 followed by a jmp phsa, you could have simplified that to jmp #3
In the example I posted, I commented to the right where the effective jump would be if the value within the jump equalled what was in the comment. For example, if the line that reads jmp #1 were to say jmp #3 instead, it would jump to line :_7 resulting in a LED sequence of %10000100
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Beau Schwabe (Parallax) said...
Anytime you do a mov phsa, #3 followed by a jmp phsa, you could have simplified that to jmp #3
No, it doesn't work like that. A jmp #3 will jump to $003 and (usuallya) continue at $004. A jmp phsx with a running counter will jump to phsxb+2*frqx and continue at phsxb+3*frqx+1.
a provided the initial jump target isn't a jump instruction bphsx value just before the jump (R cycle of previous instruction)
Ahh, I see... interesting. So when the Counter is running and tied to the Phase register, it seems as though there is a valid, calculated jump to phsxb+2*frqx. What ever that enumerates to, that's where the jump occurs, but the NEXT line of code is skipped, the remaining code is executed in a contiguous manor (see code bellow). Hmmm, I'm not sure why this happens either. It's completely different when the counter is off.
Cluso99,
[b]PUB[/b] start
[b]cognew[/b](@PASM, 0)
[b]DAT[/b] [b]org[/b] 0
PASM {00}[b]movi[/b] [b]ctra[/b], #%0_11111_000
{01}[b]mov[/b] [b]frqa[/b], #1
{02}[b]mov[/b] [b]phsa[/b], #2 '<-- Valid number are 2 through 8 for this example
{03}[b]jmp[/b] [b]phsa[/b]
{04}[b]add[/b] [b]outb[/b], #%00000001 '<-- Jumps here if phsa = 2
{05}[b]add[/b] [b]outb[/b], #%00000010 '<-- Skipped if phsa = 2 '<-- Jumps here if phsa = 3
{06}[b]add[/b] [b]outb[/b], #%00000100 '<-- Skipped if phsa = 3 '<-- Jumps here if phsa = 4
{07}[b]add[/b] [b]outb[/b], #%00001000 '<-- Skipped if phsa = 4 '<-- Jumps here if phsa = 5
{08}[b]add[/b] [b]outb[/b], #%00010000 '<-- Skipped if phsa = 5 '<-- Jumps here if phsa = 6
{09}[b]add[/b] [b]outb[/b], #%00100000 '<-- Skipped if phsa = 6 '<-- Jumps here if phsa = 7
{10}[b]add[/b] [b]outb[/b], #%01000000 '<-- Skipped if phsa = 7 '<-- Jumps here if phsa = 8
{11}[b]add[/b] [b]outb[/b], #%10000000 '<-- Skipped if phsa = 8
'Display LEDs
{12}[b]mov[/b] [b]dira[/b], LEDmask
{13}[b]shl[/b] [b]outb[/b], #16
{14}[b]mov[/b] [b]outa[/b], [b]outb[/b]
'Endless Loop
{15}[b]jmp[/b] #15
'LED mask
LEDmask [b]long[/b] %00000000_11111111_00000000_00000000
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/9/2009 5:38:12 PM GMT
And this is why the description "puzzle" is not really accurate, "mystery" would have been better [noparse]:)[/noparse] I was trying to work it out from the datasheet and manual [noparse]:)[/noparse]
Not to criticize, but at this point even though it is very obscure, it smells more like a bug than a feature. A rose by any other name ... [noparse]:)[/noparse]
My explanation of the logic involved in the Cog for kuroneko's puzzle is...
What happens is that · jmp cnt (or jmp phsx)
jumps correctly and the next instruction·is executed correctly, but the following instruction(s) is/are skipped.·The number of instructions skipped depends on the if jmp cnt (skips 1 instruction) or if jmp phsx (will skip 'frqx' value instructions).
The jmp/ret/jmpret/call will all be identical, except that the "nr" bit decides if a write occurs in the "R" phase to write the return address (for a call/jmpret) to the destination.
Remember, we are not using the instruction as intended, so this·is strictly NOT a bug or "unintended feature" (in m/soft speak!)
The·problem is that mux is being used, instead of the latched version of the mux, to supply the S address to be·copied to the pc (program counter) for a valid jump. However,·S has already incremented (cnt by 1 or frqx by #n) and the mux is supplying this, so the cog·will incorrectly store an advanced value in the pc. Subsequently, pc will be incremented ready to fetch the following instruction. This is how an instruction, or·more if phsx·was used with frqx >1, is skipped.
I believe the logic for the djnz/tjnz/tjz will just be a different version of the jump where the destination is fed to the ALU to optionally decrement
D and compare it for zero/non-zero. The "R" phase (if djnz) will write back D to the destination. If the compare was true, everything will behave as a jmp. If the result was false, the jmp will fail and the pipeline will be flushed and the current instruction will be ignored.
Chip has OK'd this info.
Now, there·has to be some use for this... Thanks to kuroneko for finding this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
>>> Remember, we are not using the instruction as intended, ....
Agreed.
>>> so this is strictly NOT a bug or "unintended feature" (in m/soft speak!)
No, it is now a rationalized behavior.
Verilog/VHDL engineers can (and often do) turn their bugs into features by providing documentation "in advance" of general use. In this case, either the consequences were never considered because it's so obscure, or the behavior was overlooked. In any event, it took a user to reveal the "feature". Now that it is understood, it should be documented so that the next user to encounter it will understand the feature and not refer to it as a bug [noparse]:)[/noparse].
jazzed said...
Now that it is understood, it should be documented so that the next user to encounter it will understand the feature and not refer to it as a bug [noparse]:)[/noparse]
Where do you suggest? waitpxx 6+ has a hard time appearing in the official PDFs (1.2.7 still mentions 5+ and 7..22 for that matter). I was wondering whether the wiki would be a good place to start?
Comments
Anytime you do a mov phsa, #3 followed by a jmp phsa, you could have simplified that to jmp #3
In the example I posted, I commented to the right where the effective jump would be if the value within the jump equalled what was in the comment. For example, if the line that reads jmp #1 were to say jmp #3 instead, it would jump to line :_7 resulting in a LED sequence of %10000100
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
a provided the initial jump target isn't a jump instruction
bphsx value just before the jump (R cycle of previous instruction)
Post Edited (kuroneko) : 12/9/2009 3:09:01 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Ahh, I see... interesting. So when the Counter is running and tied to the Phase register, it seems as though there is a valid, calculated jump to phsxb+2*frqx. What ever that enumerates to, that's where the jump occurs, but the NEXT line of code is skipped, the remaining code is executed in a contiguous manor (see code bellow). Hmmm, I'm not sure why this happens either. It's completely different when the counter is off.
Cluso99,
[b]PUB[/b] start [b]cognew[/b](@PASM, 0) [b]DAT[/b] [b]org[/b] 0 PASM {00}[b]movi[/b] [b]ctra[/b], #%0_11111_000 {01}[b]mov[/b] [b]frqa[/b], #1 {02}[b]mov[/b] [b]phsa[/b], #2 '<-- Valid number are 2 through 8 for this example {03}[b]jmp[/b] [b]phsa[/b] {04}[b]add[/b] [b]outb[/b], #%00000001 '<-- Jumps here if phsa = 2 {05}[b]add[/b] [b]outb[/b], #%00000010 '<-- Skipped if phsa = 2 '<-- Jumps here if phsa = 3 {06}[b]add[/b] [b]outb[/b], #%00000100 '<-- Skipped if phsa = 3 '<-- Jumps here if phsa = 4 {07}[b]add[/b] [b]outb[/b], #%00001000 '<-- Skipped if phsa = 4 '<-- Jumps here if phsa = 5 {08}[b]add[/b] [b]outb[/b], #%00010000 '<-- Skipped if phsa = 5 '<-- Jumps here if phsa = 6 {09}[b]add[/b] [b]outb[/b], #%00100000 '<-- Skipped if phsa = 6 '<-- Jumps here if phsa = 7 {10}[b]add[/b] [b]outb[/b], #%01000000 '<-- Skipped if phsa = 7 '<-- Jumps here if phsa = 8 {11}[b]add[/b] [b]outb[/b], #%10000000 '<-- Skipped if phsa = 8 'Display LEDs {12}[b]mov[/b] [b]dira[/b], LEDmask {13}[b]shl[/b] [b]outb[/b], #16 {14}[b]mov[/b] [b]outa[/b], [b]outb[/b] 'Endless Loop {15}[b]jmp[/b] #15 'LED mask LEDmask [b]long[/b] %00000000_11111111_00000000_00000000▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/9/2009 5:38:12 PM GMT
Graham
What happens is that
· jmp cnt (or jmp phsx)
jumps correctly and the next instruction·is executed correctly, but the following instruction(s) is/are skipped.·The number of instructions skipped depends on the if jmp cnt (skips 1 instruction) or if jmp phsx (will skip 'frqx' value instructions).
The jmp/ret/jmpret/call will all be identical, except that the "nr" bit decides if a write occurs in the "R" phase to write the return address (for a call/jmpret) to the destination.
Remember, we are not using the instruction as intended, so this·is strictly NOT a bug or "unintended feature" (in m/soft speak!)
The·problem is that mux is being used, instead of the latched version of the mux, to supply the S address to be·copied to the pc (program counter) for a valid jump. However,·S has already incremented (cnt by 1 or frqx by #n) and the mux is supplying this, so the cog·will incorrectly store an advanced value in the pc. Subsequently, pc will be incremented ready to fetch the following instruction. This is how an instruction, or·more if phsx·was used with frqx >1, is skipped.
I believe the logic for the djnz/tjnz/tjz will just be a different version of the jump where the destination is fed to the ALU to optionally decrement
D and compare it for zero/non-zero. The "R" phase (if djnz) will write back D to the destination. If the compare was true, everything will behave as a jmp. If the result was false, the jmp will fail and the pipeline will be flushed and the current instruction will be ignored.
Chip has OK'd this info.
Now, there·has to be some use for this... Thanks to kuroneko for finding this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Agreed.
>>> so this is strictly NOT a bug or "unintended feature" (in m/soft speak!)
No, it is now a rationalized behavior.
Verilog/VHDL engineers can (and often do) turn their bugs into features by providing documentation "in advance" of general use. In this case, either the consequences were never considered because it's so obscure, or the behavior was overlooked. In any event, it took a user to reveal the "feature". Now that it is understood, it should be documented so that the next user to encounter it will understand the feature and not refer to it as a bug [noparse]:)[/noparse].
Propeller Tricks & Traps: http://forums.parallax.com/showthread.php?p=575479