DAT variable alignment

James Newman

Ok, I have 8 bytes, and 30 longs I need right next to each other in memory. I would like to keep each declared as byte/long respectively so that array access doesn't need to be typecast every time I access them. IE: If I declared the 8 bytes as 2 longs, I would then have to access the bytes like: byte[noparse][[/noparse]foo] for the second byte. Doing this in the Var area is hard due to the rearrangement of variables when compiled. So I've moved it all to the Dat section. Now, my next problem, is if the bytes aren't long aligned, then padding -could- get in the way. Sooooo.... I've come up with this idea, and it seems to work, but I'm posting to get some conformation. I would hate to have a problem later with this as it could be hard to debug. This is what I've got:

DAT
'Data
alignme       long
name          byte      " TEMP  ",0      
stuff        long      0[noparse][[/noparse] 30 ]

Now if I'm right, that should always result in the 'name' being aligned and -next to- the 'stuff'. While still allowing them to be referenced as bytes, and longs respectively.

Does that make sense to anyone else?, and am I correct?

Mike Green

Yes. As long as name is a multiple of 4 bytes in length, there won't be any extra padding inserted by the assembler before stuff.

deSilva

The construct

label   SIZE

is not well described neither in the Manual nor in the Errata..
I know it "works" what you do, but I have no reference to support that.

CardboardGuru

deSilva,

The section on DAT in the manual covers the alignment issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

deSilva

Oh, dear! Yes, its all in the manual.. pp 208 to 211.
I think I will be not the only one who wasn't aware that

label  BYTE LONG $01020304

is a valid and useful expression....

James Newman

Ohhh, that -is- useful, and would better explain why my above code works. I had checked in the manual, but I was using the information around page 166. I'm glad deSilva posted the pages to look at, or I would have never found it.

Well, I'm glad I asked, thanks for the help everyone. I'm going to go simplify that area of my code now

EDIT: Ohhh and deSilva, unless I'm mistaken 'label BYTE LONG $01020304' isn't a useful expression. -label- would be byte-aligned and long-sized. Longs are always byte aligned. [noparse];)[/noparse]

EDIT2: Ok... I'm missing something I think. 'label LONG BYTE "Blah"' Doesn't work. It seems that the 'size override' must be larger than the alignment. I don't quite see the point in that... I guess you could have short-aligned longs, but other than that... what's the point? byte aligned longs/words doesn't make sense, aren't they always byte aligned? I need Long aligned Bytes, but that doesn't seem to work...

I think my previous code works... but this would have been more elegant. Can anyone point out what I'm missing?

EDIT3: Ok (I say that alot...) If I declared a long as byte-aligned, then it wouldn't pad the previous value to get to a long-aligned value... that makes sense. But, since I can't do a long-aligned byte, I still have to use my original code above... right? Sorry if I seem a bit off, trying to figure this out....

Post Edited (James Newman) : 12/12/2007 12:03:41 AM GMT

CardboardGuru

Hi James,
Consider this, which happens to start at $0400 in memory:

DAT
label1 long 1
label2 byte 2
label3 long 3

That produces the following sequence of bytes in memory:

$0400: 01 00 00 00 'long aligned long
$0404: 02 00 00 00 'byte plus three bytes of padding
$0408: 03 00 00 00 'long aligned long

Suppose instead you do
DAT
label1 long 1
label2 byte 2
label2 byte long 3

Then you'd get:
$0400: 01 00 00 00 'long aligned long
$0404: 02 'byte
$0405: 03 00 00 00 'byte aligned long

See how how second long doesn't have to start on a 4 byte boundary because it is byte aligned rather than long aligned.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK

James Newman

CardboardGuru> Ya, I figured that out (I have 4 edits to my last post ), and that makes sense to me. I was trying to long-align my bytes, but your example has just made me aware that I don't need to... I can just byte align my long array that follows, and that will work. I do wonder if that will have any speed issues when accessing those longs though? The advantage of long-aligning the bytes, preceding the array of longs, was that everything would still be aligned to their own sizes too. (Ie, the bytes still lie on byte-address boundaries, and the longs still lie on long-address boundaries.)

CardboardGuru

James Newman said...
I can just byte align my long array that follows, and that will work. I do wonder if that will have any speed issues when accessing those longs though?

It's worse than that. Neither Spin nor the assembler will let you read longs that are not long aligned or words that are not word aligned. You'd have to read them as bytes, and combine them together to reconstitute a long or word yourself.

So unless you have a very good reason to do so, you really don't want to go there. (A good reason being a pre-existing data format that you need to follow for some reason).

The best thing to do is to group all longs together, all words together, and all bytes together, and then not worry about the maximum possible 3 bytes per program you've wasted.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK