Memory adresses...

siljamicke

Ok, i'm getting more and more confused...

Memory cells inside a cog is adressed in longs, right? Meaning that if i increment a pointer to a cog-cell by one, i would have skipped to the next long in memory? And if i would like only one byte from cog-memory i would have to extract it from the long containing it, since i cannot adress individual bytes? Is this correct?

But what about hub-memory? This memory is byte-adressed,or? Meaning that if i increment a pointer by one, i would have skipped a byte, and not a long?

So if i have an array of longs, like this:

VAR
long Array[32]

And want to access each item in that array from my assembler program, would i do like this then:

cognew(@someprg, @Array[0])

DAT
mov r, PAR
rdlong a1, r
add r, [COLOR="red"]#1[/COLOR]
rdlong a2, r
add r, [COLOR="red"]#1[/COLOR]

etc..

or:

cognew(@someprg, @Array[0])

DAT
mov r, PAR
rdlong a1, r
add r, [COLOR="red"]#4[/COLOR]
rdlong a2, r
add r, [COLOR="red"]#4[/COLOR]

etc..

Furthermore, if it was an array of bytes instead of longs, which is it then?

siljamicke

Basically, what i'm asking is; what number does PAR contain in these cases?

I have an array in my program with pseudo-registers to pass data between cogs, sort of like this:

Data[2]

cognew(@cog1, Data[0])
cognew(@cog2, Data[0])
cognew(@cog3, Data[1])


DAT
        org 0
cog1
        mov ptr, par
        wrlong someData, ptr
stop        
        jmp #stop


        org 0

cog2
        mov ptr, par
        rdlong someData, ptr
        
       'modify data...

       add ptr, [COLOR="red"]#4[/COLOR]
       wrlong someData, ptr

stopAgain        
        jmp #stopAgain

cog3
        rdlong someData, par
        
       'output data...
       
stopDamnit        
        jmp #stopDamnit
        

Is this correct? I'm getting weird bugs that sometimes is fixed by changing #4 into #1, and sometimes the reverse is true... Gah...

Mike Green

Cog memory contains longs and is addressed as longs as you have shown. Hub memory contains bytes and is addressed as bytes. Words are addressed at even memory addresses and consist of two bytes accessed simultaneously. Longs are addressed at memory addresses divisible by 4 and consist of four bytes accessed simultaneously. The Propeller ignores the least significant bit of hub addresses used to access words. It ignores the least significant two bits of hub addresses used to access longs.

If you copy an array of longs from hub memory to cog memory, the hub memory address is incremented by 4 and the cog memory is incremented by 1 as each long is copied.

PAR is assumed to contain the address of a long. The hardware doesn't include the low order two bits of whatever you supply to the COGNEW nor does it include anything beyond 16 bits. In other words, you can pass a value divisible by 4, less than 65536 and anything else is discarded.

MagIO2

If you want to access HUB RAM you also can use WRWORD, RDWORD, WRBYTE and RDBYTE. The address you use there is in general a byte address, but for words and longs it's alligned by setting the least significant bits to zero. So, if you do

RDWORD buffer, hubadr
where hubadr contains $7fff it will really read the word from $7ffe.
RDLONG would read the long from $7ffc.

In other words, if you loop through bytes you'd add #1, if you loop through words you'd add #2 and for longs you'd add #4. Otherwise you'd read the same word twice or the same long 4 times.

You should also know that PAR is expected to be a LONG alligned address, as here the 2 least significant bits are also zero - always!
So, if you want to pass a byte-address you should put this address into a long and pass this address. So your PASM code first has to read the byte-address from the location that PAR points to.

MagIO2

Tztz ... last week it was JonnyMac, this time it's Mike ... guess I should simply stop posting ... I'm always to late lately ;o)

siljamicke

So utilising rdbyte means a waste of memory, as i can never reach the misaligned bytes? A usable byte from a cog uses up a long in hub-ram? I think i understand, but it hasn't sunk in yet...

@MaglO2:
You saved my a** a week ago or so, so don't feel sad, i'm already grateful to you!

MagIO2

No, in HUB you have byte access. You can access each single byte by using WR/RDBYTE. You can access each single word by using WR/RDWORD by using a word alligned address. Or each single long with WR/RDLONG by using a long alligned address.

You'd only waste COG RAM, if you use RDBYTE to load it into COG RAM by simply increasing the COG RAM address pointer as this would only use the least significant byte of the COG RAM register. But you can do it better if you want. You can simply copy (buffer_size+3)/4 longs instead of buffer_size bytes which is a lot faster, as you have divided the number of HUB RAM accesses.
Then you need shift and mask-operations in the COG if you want to process that data bytewise.

MagIO2

Each of address in HUB RAM contains a byte. Let's say we filled the first bytes with it's address+1
With RDBYTE/WORD/LONG data, hub_adr you read the following

hub_adr | content | RDBYTE |   data  | RDWORD |   data  | RDLONG |   data
$0000   |  $01    | $0000  |$00000001|  $0000 |$00000201|  $0000 |$04030201  
$0001   |  $02    | $0001  |$00000002|  $0000 |$00000201|  $0000 |$04030201
$0002   |  $03    | $0002  |$00000003|  $0002 |$00000403|  $0000 |$04030201
$0003   |  $04    | $0003  |$00000004|  $0002 |$00000403|  $0000 |$04030201
$0004   |  $05    | $0004  |$00000005|  $0004 |$00000605|  $0004 |$08070605

Hope that helps.

siljamicke

It certainly does!

Thanks both Mike and MaglO2!