An Observation on PASM Hub Operations
jazzed
Posts: 11,803
Over in the Sandbox dMajo and I had a little discussion about HUB operations.
This may be obvious to some PASM users, but it took a while for me to get it.
Hopefully, this will help new PASM users interested in performance in a small way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools Post Edited (jazzed) : 9/10/2009 11:07:05 PM GMT
This may be obvious to some PASM users, but it took a while for me to get it.
dat org 0 ' blah blah blah ' just for demo sake assume val and ptr are defined and ptr is set to some address ' that can contain 0 or non-zero. ' this code creates a tight squarewave on P0 until the rdlong command results in zero ' there are only 2 instructions between hub ops, so the squarewave does not have jitter :loop rdlong val, ptr wz xor outa, #1 if_nz jmp #:loop ' this code creates a squarewave on P0 at half the frequency of the previous :loop ' there are 3 instructions between hub ops, so missing the hub window makes the pulses wider :loop2 rdlong val, ptr wz xor outa, #1 nop if_nz jmp #:loop2 ' what does this code do besides waste a lot of cycles? ' [b]It produces exactly the same squarewave on P0 as in example :loop2. ' Effectively, you get 12 more cycles to waste than you may have realized before :)[/b] :loop3 rdlong val, ptr wz xor outa, #1 nop nop nop nop if_nz jmp #:loop3
Hopefully, this will help new PASM users interested in performance in a small way.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools Post Edited (jazzed) : 9/10/2009 11:07:05 PM GMT
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Another thing I try to do is to make full use of the 9 cycles between hub accesses by inserting two 4 cycle operations between them...· that results in any following hub commands only requiring 8 cycles and minimizes 'cycle waste'.
edit -
> Neither the 2nd nor the 3rd example should cause jitter. They should simply make the loop longer.
You have a good eye ;-)
As for the topic at hand, jitter could become an issue if you were using a seperate rdlong to obtain each pin state rather than simply xor'ing, and these rdlongs were not synchronized.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (Agent420) : 9/10/2009 8:00:06 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
-Phil
The real point I was trying to make is: If you go over the "between hub access" the magic clock cycle limits, you get approximately 16 more cycles before the next "hub window" expires. I wanted to thank dMajo for helping me understand this better and share it with the greater forum especially since it's never really been brought up before that I know of.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
-Phil