Cog Symbol Must be long Aligned error

Bob Drury · 2021-11-10 22:39

Using propeller 1 manual went through what byte\word\long aligned means. It seemed to imply that padding characters were installed by compiler. Why does following code run with only one type of debug statement in PASM code:
debug(udec_byte(cogByteData))
'debug(udec_word(cogWordData))
'debug(udec_long(cogLongData))
When two debug statements error occurs:
debug(udec_byte(cogByteData))
debug(udec_word(cogWordData))
'debug(udec_long(cogLongData))
I understand that cog registers are 32 bit longs but when you declare byte how is data stored in a cog?
Are 3 bytes padded "0"or are bytes packed with 4 bytes per register. Below is code trying to run:

Con
  _clkfreq = 200_000_000
VAR
Byte  HubByte[20]
Word  HubWord
Long  HubLong
Pub main()|x,y
    regload(@CogCodePrm)
    y := strsize(@hubByteData)
    debug(udec(y))
    repeat x from 0 to y
        debug(udec(x),udec_byte(hubByteData[x]))
    repeat x from 0 to 7
        debug(udec(x),udec_word(hubWordData[x]))
    repeat x from 0 to 7
        debug(udec(x),udec_long(hubLongData[x]))
    call(@strtCogCode1)
    call(@strtCogCode2)
    repeat
DAT
              orgh
hubByteData   Byte "Hello Propeller",0
hubWordData   Word  $F000,$F001,$F002,$F003,$F004,$F005,$F006,$F007
hubLongData   Long  $F000_0000,$F000_0001,$F000_0002,$F000_0003,$F000_0004,$F000_0005,$F000_0006,$F000_0007
DAT
CogCodePrm      word   strtCogCode1,endCogCode-strtCogCode1-1
                  ORG 0
strtCogCode1      nop
                  debug(udec_byte(cogByteData))
                  'debug(udec_word(cogWordData))
                  'debug(udec_long(cogLongData))
                  ret
strtCogCode2      nop
                  debug(udec_byte(cogByteData))
                  'debug(udec_word(cogWordData))
                  'debug(udec_long(cogLongData))
                  ret
cogByteData    Byte   "abcdefghijklmnopqrstuvwxz",0 
'cogWordData    Word   $F000,$F001,$F002,$F003,$F004,$F005,$F006,$F007
'cogLongData    Long   $F000_0000,$F000_0001,$F000_0002,$F000_0003,$F000_0004,$F000_0005,$F000_0006,$F000_0007  
endCogCode

regards and thanks
Bob (WRD)

evanh · 2021-11-11 01:27

It'll still be packed (without padding), same way as hubRAM. That's effectively mixing Pasm with Spin again. Use ALIGNL keyword to add padding.

evanh · 2021-11-11 01:29

I suppose everything in DAT section is considered Pasm. The ancient "instructions.txt" file has brief on pure Pasm syntax ... which has been tacked onto the end of the silicon document as well - Under section name Assembly Language.

Bob Drury · 2021-11-11 04:44

I looked at assembly language in silicon document and it mentions following
ALIGNW/ALIGNL
Align to next word/long in hub.
BYTE data{[count]}{,data{[count]}...}
WORD data{[count]}{,data{[count]}...}
LONG data{[count]}{,data{[count]}...}
There is no explanation of what the issue is for aligning (I was under the impression that was a compiler function for packing data into DAT file) or when and how to use ALIGNW\ALIGNL (I assume ALIGNW is align word and ALIGNL is align Long)
I did find some prop 1 manual stuff " byte 64,"text" word $FFFF" for packing data to override compiler alignment padding . This alignment thing is a bit of a mystery to me any pointers apreciated. Where do I find "instruction.txt"?
Regards and Thanks
Bob (WRD)

evanh · 2021-11-11 04:54

The silicon doc has a verbatim copy, the whole instruction.txt is in there. That's why that section looks so messy.

All they do is add padding, at the keyword, in the binary file. If the file doesn't get loaded in the appropriate location then all bets are off as to whether the keywords are effective or not.

evanh · 2021-11-11 04:57

Here I've used ALIGNL to fix the compile error:

DAT
CogCodePrm      word   strtCogCode1,endCogCode-strtCogCode1-1
                  ORG 0
strtCogCode1      nop
                  debug(udec_byte(cogByteData))
                  'debug(udec_word(cogWordData))
                  'debug(udec_long(cogLongData))
                  ret
strtCogCode2      nop
                  debug(udec_byte(cogByteData))
                  'debug(udec_word(cogWordData))
                  'debug(udec_long(cogLongData))
                  ret
cogByteData    Byte   "abcdefghijklmnopqrstuvwxz",0
ALIGNL
cogWordData    Word   $F000,$F001,$F002,$F003,$F004,$F005,$F006,$F007
ALIGNL
cogLongData    Long   $F000_0000,$F000_0001,$F000_0002,$F000_0003,$F000_0004,$F000_0005,$F000_0006,$F000_0007  
endCogCode

evanh · 2021-11-11 05:25

ALIGNW/ALIGNL work relative to the ORG/ORGH keywords. The assembler/compiler builds the binary based on the specified address. But those addresses don't define the runtime file load address.

That's the nature of how low level assembly is. The load address may need to be embedded in an extra piece of code that you write in the program itself.

This extra effort also provides the ultimate in flexibility. Total control of the hardware. It's the world of loaders and OS booting.

Ariba · 2021-11-11 11:16

In Spin for Prop1 the WORD and LONG directives in DAT did automatically align the addresses. The reason was that P1 could only access words and longs on aligned addresses.
The P2 can access words and longs also from unaligned addresses, that's why WORD and LONG don't align the addresses automatically now, and ALIGNW and ALIGNL exist instead. But these unaligned accesses are only possible for data access, using RDWORD, RDLONG etc. It's different for code and registers inside cogmemory, because cog memory is made from 32bit wide RAM. This means in the hub image the code and registers must be long aligned relative to the ORG, before transfered into cog memory, otherwise the addresses just don't match.

Andy

evanh · 2021-11-11 12:07

Code can be unaligned in hubexec, the FIFO just takes an extra tick for initial fetching upon branch. Very earliest days of hubexec I think it was longword bound but Chip quickly changed it. That was when he was wrestling with which solution to use for branch address instruction encodings.

Rayman · 2021-11-11 17:52

@evanh said:
Code can be unaligned in hubexec, the FIFO just takes an extra tick for initial fetching upon branch. Very earliest days of hubexec I think it was longword bound but Chip quickly changed it. That was when he was wrestling with which solution to use for branch address instruction encodings.

I guess I forgot about that... Kind of surprising that can work...

evanh · 2021-11-11 20:39

Thinking about it, Chip probably decided to go with allowing unaligned hubexec because it was practically for free - Everything was in place already: The FIFO naturally presents as longwords to the instruction pipeline - eliminating the need for any special buffers. And the unaligned read/write support was already in place at the eggbeater - for unaligned data accesses.

The only hurdle was sorting out the cog/hub split in code addressing models and instruction encodings. There was a few factors to juggle before he settled on what we have. One was the mapping of hubexec from $400 up. I don't remember all the details though.

Rayman · 2021-11-11 21:06

Ok, I see the FIFO gets longs that are aligned correctly. That makes it easier...

Cog Symbol Must be long Aligned error

Comments