Incrementing Long Address in Cog Memory, PASM

gis667en11

So, I think I've done my due diligence in looking for the answer to this. I've spent well over an hour digging through the manual and forums. I'm looking at the I2C PP PASM driver by Chris Gadd. I'm using it as a case study, since I'm still pretty new to PASM programming, and I'm having trouble interpreting this loop:

                        org
entry
                        mov       t1,par                                        ' Load parameter addresses
                        rdlong    bit_delay,t1
                        add       t1,#4
                        movd      :loop,#command_address
                        mov       loop_counter,#7
:loop                   mov       0-0,t1
                        add       t1,#4
                        add       :loop,d1
                        djnz      loop_counter,#:loop
                        rdbyte    t2,t1
                        mov       SCL_mask,#1                                   ' Create masks for clock and data pins
                        shl       SCL_mask,t2
                        add       t1,#1
                        rdbyte    t2,t1
                        mov       SDA_mask,#1
                        shl       SDA_mask,t2
                        or        outa,SDA_mask
                        or        outa,SCL_mask
                        or        dira,SDA_mask
                        or        dira,SCL_mask

Now, none of that is really above my head, even the movd, except for the value of d1. It's used to increment through reserved long data symbols for initializing the PASM program after it's launched into a new cog. d1 is |< 9. So it's %0000 0010 0000 0000. How does that increment the cog memory address to the next reserved long? Why wouldn't it just be adding #1? What is this wizardry?

This is the driver link

Phil Pilgrim (PhiPi)

|<9 increments the destination field of the instruction by one. The destination field is instruction[17..9]. The source field is instruction[8..0].

-Phil

gis667en11

OOOHHH snap that makes perfect sense. Thanks Phil, I get it now. Wow, that loop is crazy efficient.

Keith Young

Man Phil I just have to say it amazes me when people can come in, read code like this someone else wrote, and come straight back with an answer.