这个是编译器的内存对齐问题吗？

jetking

1. uint8_t buf[]={0,1,2,3,4};
   
2. uint32_t *t=(uint32_t *)buf;
   
3. printf("%08x\n",*t);

复制代码

在pc上，打印出03020100,
但是在arm小端平台上，编译器是codesourcery的arm-q3，结果不是03020100,后做实验发现只有sizeof(buf)是4的倍数，这时结果是正确的。
这个是不是编译器的bug呢？

版主，这个涉及到嵌入式，但请不要移到嵌入式开发板块，c板块大牛多！谢谢！

jnjn999

帮顶……

nizvoo

在pc上，打印出03020100,
但是在arm小端平台上，编译器是codesourcery的arm-q3，结果不是03020100,后做实验 ...
jetking 发表于 2011-03-24 20:12

    你結果是多少？

liwangli1983

字符串数组，起始地址不一定是四字节对齐的。对于ARM体系来说，如果访问的32位整数不是4字节对齐的，是会总线错误的（相对我们用的PC，不对齐仅仅是速度变慢）

jetking

00020100

egmkang

uint8_t buf[]={0,1,2,3,4};
uint32_t t=(buf[0]<<0) | (buf[1]<<8 ) | (buf[2]<<16) | (buf[3]<<24);

是这样么

b86873564

果然是牛人多

jetking

字符串数组，起始地址不一定是四字节对齐的。对于ARM体系来说，如果访问的32位整数不是4字节对齐的，是会总 ...
liwangli1983 发表于 2011-03-24 20:42

    这是不是就意味着，上述的用法，不具备移植性，在某些平台下面有陷阱，要避免。

jetking

uint8_t buf[]={0,1,2,3,4};
uint32_t t=(buf[0]
egmkang 发表于 2011-03-24 20:46

这样当然可以，memcpy 4个字节也可以。本来是用在一个数据头判断前4个字节是否匹配，不需要再赋值。

liwangli1983

这是不是就意味着，上述的用法，不具备移植性，在某些平台下面有陷阱，要避免。
jetking 发表于 2011-03-25 09:24

    算是吧，其实任何平台都最好不要这样做，就算是X86这样允许非对齐访问的体系，也会带来性能下降的问题．
    非要这么用的话，你可以用gnu编译扩展，让编译时候强制把数组首地址按四字节对齐，就可以了．不过这样将来如果需要用别的编译器编译，可能还得再改代码．