wrword error question

David B · 2015-02-05 15:25

What's illegal about using a word variable for wrword when writing to a word hub address?

If the commented line is uncommented, the propeller tool says "Error: Address is not long." Otherwise the code works as expected.

DAT

org 0

test_cog   
        mov     data_pointer, par
        wrword  a_long_1, data_pointer                
        add     data_pointer, #2
        wrword  a_long_2, data_pointer

        add     data_pointer, #2
        wrword  a_word_1, data_pointer                
        add     data_pointer, #2
    '    wrword  a_word_2, data_pointer  ' <- compiler says "Error: Address is not long."
       
idle    jmp     #idle

a_long_1        long 1
a_long_2        long 2

a_word_1        word 3 
a_word_2        word 4

data_pointer    res 1

Phil Pilgrim (PhiPi) · 2015-02-05 15:42

Words don't actually exist in cog RAM, since cog addresses increment by one for each long. So there's no way in a cog to reference a cog word that's not long aligned in the hub. To write a_word_2 to the hub, do it this way:

        mov      temp,a_word_1
        shr      temp,#16
        wrword   temp,data_pointer

... or, if you don't want to use a temporary variable:

        ror     a_word_1,#16
        wrword  a_word_1,data_pointer
        ror     a_word_1,#16

-Phil

ozpropdev · 2015-02-05 15:42

Only LONG directives can be used within PASM code.

David B · 2015-02-05 15:58

Thanks. I can make the variables longs and get the asm to work, but it seemed like it would have been more consistent to use word variables in places where the data will only be words. It seemed kind of odd that they are allowed to be declared but are not allowed to be used.

Phil Pilgrim (PhiPi) · 2015-02-05 16:13

They are allowed to be used as word variables ... in the hub, but not in the cog. Since cog addresses are nine bits long, there are only 512 discrete locations possible there. If the cog addressing granualrity were word-sized instead of long-sized, cog RAM would be half as long as it is now. If the granuarity were byte-sized, a quarter of what it is now. So I think the current design is the correct one.

-Phil

Rayman · 2015-02-05 16:41

I think life is a whole lot easier if you only use longs in your assembly code...

Unless you have a large table in bytes or words, it's probably not worth the trouble...

Phil Pilgrim (PhiPi) · 2015-02-05 17:35

If you have a table of bytes or words -- no matter what the size -- it's easier in PASM to access them from the hub.

-Phil

Electrodude · 2015-02-05 18:37

Phil Pilgrim (PhiPi) wrote: »

If you have a table of bytes or words -- no matter what the size -- it's easier in PASM to access them from the hub.

-Phil

It's usually faster, too, except with worst-case hub timing, and it definitely uses less cogram.

hubram:

mov tmp, baseptr ' 4 ticks
mov tmp, offset  ' 4 ticks
rdbyte tmp, tmp  ' 7..22 ticks
          ' total 15..30 ticks

cogram:

{mostly stolen from Spin Interpreter}
ror tmp, #2      ' 4 ticks
add tmp, baseptr ' 4 ticks
movs $+2, tmp    ' 4 ticks
shr tmp, #27     ' 4 ticks
mov tmp, 0-0     ' 4 ticks
shr tmp, offset  ' 4 ticks
and tmp, #$FF    ' 4 ticks
          ' total 28 ticks

David B · 2015-02-05 23:13

I have a 16 bit ADC running from one cog, writing to a long location in the hub, with a application in another cog reading the values from the single long hub location on a timed basis.

But I wanted to convert it to have the adc write to a several K sized hub array as a circular buffer where since it only uses 16 bits, writing longs would be really wasteful of ram.

It looks like it's working now; it was just that word declaration thing that caught me by surprise.

tonyp12 · 2015-02-06 07:26

If you want speed and no shifting in cog, temporary store all 16bit data in the cog as 32bit long, the upper 16bits could be used for something else if you need flags etc.
Every time you want to send the lower 16bit of those longs, you do this below and you will not waste any HUB ram
Though I see that hub access will stall as 2 (regular) cog instructions in between is fastest, so optional put 2 more instruction in the loop that does something useful.

        ...
        mov   hubaddrs, PAR 
        movd  loop,     #cogbuffer   ' restore table pointer
        mov   buffcnt,  #16
loop    wrword 0-0,     hubaddrs
        add   loop,     _bit9
        add   hubaddrs, #2
        djnz  buffcnt,  #loop        

_bit9     long |<9
hubaddrs  res 1
buffcnt   res 1
cogbuffer res 16

wrword error question

Comments