Canon ARM endianness, and GCC packing...

[toinech]

ARM:
Anybody knows what is the endianness of the ARM processor?
Can ARM processor load an "unsigned int" on an odd address (ie not aligned)?
Can ARM processor load an "unsigned long" on an odd address (ie not dword or word aligned)?

GCC:
Let's say we have the following struct
struct {
   unsigned char byte0
   unsigned long byte1to5
} fivebytes1;

struct {
   unsigned long byte0to4
   unsigned char byte5
} fivebytes2;

fivebytes1 * p1;
fivebytes2 * p2;
unsigned char *pc1;
unsigned char *pc2;

What will be the value of pc2-pc1 assuming the following?
pc1 = (unsigned char *) p1;
p1++;
pc2 = (unsigned char *) p1;

What will be the value of pc2-pc1 assuming the following?
pc1 = (unsigned char *) p2;
p2++;
pc2 = (unsigned char *) p2;

[ewavr]

ARM:
Can ARM processor load an "unsigned int" on an odd address (ie not aligned)?
Can ARM processor load an "unsigned long" on an odd address (ie not dword or word aligned)?

I have negative experience on this (instruction seems correct, but return wrong value). But you can make own investigation (or read manuals)...

GCC:
Let's say we have the following struct
struct {
   unsigned char byte0
   unsigned long byte1to5
} fivebytes1;

By default sizeof(fivebytes1) is 8 (DWORD aligned).  Use #pragma pack(n) to make own alignment.

edit: Of course, I may be wrong here 

[GrAnd]

As EWAVR said, It depends on is the structure is packed or not. ARM processor can manage non-aligned data. But ARM code is 4byte aligned (unless it is thumb-code).

For example:

Code: C

1. struct fivebytes1 {
2.    unsigned char byte0;
3.    unsigned long byte1to5;
4. };
5.  
6. struct fivebytes2 {
7.    unsigned long byte0to4;
8.    unsigned char byte5;
9. };
10.  
11. struct fivebytes1p {
12.    unsigned char byte0;
13.    unsigned long byte1to5;
14. } __attribute__((__packed__));
15.  
16. struct fivebytes2p {
17.    unsigned long byte0to4;
18.    unsigned char byte5;
19. } __attribute__((__packed__));
20.  
21.  
22. const struct fivebytes1  fb1  = {0xAA, 0x12345678};
23. const struct fivebytes2  fb2  = {0x12345678, 0xAA};
24. const struct fivebytes1p fb1p = {0xAA, 0x12345678};
25. const struct fivebytes2p fb2p = {0x12345678, 0xAA};
26.  

Creates the following:

Code: ASM

1. .rodata:0000004C ; Segment type: Pure data
2. .rodata:0000004C                 AREA .rodata, DATA, READONLY
3. .rodata:0000004C                 ; ORG 0x4C
4. .rodata:0000004C                 EXPORT fb1
5. .rodata:0000004C fb1             DCB 0xAA, 0, 0, 0, 0x78, 0x56, 0x34, 0x12
6. .rodata:00000054                 EXPORT fb2
7. .rodata:00000054 fb2             DCB 0x78, 0x56, 0x34, 0x12, 0xAA, 0, 0, 0
8. .rodata:0000005C                 EXPORT fb1p
9. .rodata:0000005C fb1p            DCB 0xAA, 0x78, 0x56, 0x34, 0x12
10. .rodata:00000061                 EXPORT fb2p
11. .rodata:00000061 fb2p            DCB 0x78, 0x56, 0x34, 0x12, 0xAA
12. .rodata:00000066                 ALIGN 4
13. .rodata:00000066 ; _rodata       ends
14.  

[ewavr]

Someting is wrong here...

char xxx[]={1,2,3,4,5,6,7,8};

sprintf(osd_buf, "%08x  ", *(unsigned long*) xxx);
output: 04030201 - correct

sprintf(osd_buf, "%08x  ", *(unsigned long*) (xxx+1));
output: 01040302 - incorrect

sprintf(osd_buf, "%08x  ", *(unsigned long*) (xxx+2));
output: 02010403 - incorrect

sprintf(osd_buf, "%08x  ", *(unsigned long*) (xxx+4));
output: 08070605 - correct

[DataGhost]

[GrAnd]

Something is wrong here...

May be bug in sprintf?
Is the math is also incorrect? For example:

char xxx[]={1,2,3,4,5,6,7,8};
unsigned long res;

res = (*(unsigned long*) (xxx+1)) - (*(unsigned long*) (xxx));
sprintf(osd_buf, "%08x  ", res);

res = (*(unsigned long*) (xxx+2)) - (*(unsigned long*) (xxx));
sprintf(osd_buf, "%08x  ", res);

res = (*(unsigned long*) (xxx+2)) - (*(unsigned long*) (xxx+1));
sprintf(osd_buf, "%08x  ", res);

res = (*(unsigned long*) (xxx+4)) - (*(unsigned long*) (xxx));
sprintf(osd_buf, "%08x  ", res);

[ewavr]

May be bug in sprintf?

May be or maybe? 

char xxx[]={1,2,3,4,5,6,7,8};
unsigned long res;
res= *(unsigned long*) (xxx);
sprintf(osd_buf, "4:%08x  ",res );

output: 04030201 - correct
assembler:

ldr   r1, [pc, #408] ;  "4:%08x  "
ldr   r2, [sp, #64]  ;  *(unsigned long*) (xxx)
adds   r0, r4, #0      ;   osd_buf[]
bl   af004 <__sprintf_from_thumb>

Now:

char xxx[]={1,2,3,4,5,6,7,8};
unsigned long res;
res= *(unsigned long*) (xxx+1);
sprintf(osd_buf, "4:%08x  ",res );

output: 01040302 - incorrect

assembler:
mov   r3, sp             
adds   r3, #65         
ldr   r2, [r3, #0]     ; res= *(unsigned long*) (xxx+1) - not too smart compiler 
ldr   r1, [pc, #408]    ;  "4:%08x  "
adds   r0, r4, #0  ;   osd_buf[]
bl   af008 <__sprintf_from_thumb>

So, "ldr r2, [sp, #64]"  - correct data, "ldr r2, [sp, #65]"  - incorrect data.

[DataGhost]

Well, the data is technically correct, if you look at the architecture implementation/notes. The result is just not what you'd expect but I guess that's just something to keep in mind. I think it's a limitation of the MMU which would otherwise require 2 loads from memory or it just wasn't implemented for sake of simplicity. In some cases, it might even be useful, as loading and rotating can happen in one operation, though it's probably only noticable (performance-wise) in a really, really tight and often-executed loop.

[ewavr]

I guess it does load the values but stays within the word boundary and then shifts the value somehow. This is probably documented or documented as 'undefined', I'll see if I can find something in the ARM docs

Why yes, I can.

Unfortunately, I do not have time to read this. Now, everything is clear to me.