免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 3854 | 回复: 10

[C] 这个是编译器的内存对齐问题吗? [复制链接]

论坛徽章:
0
发表于 2011-03-24 20:12 |显示全部楼层
  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板块大牛多!谢谢!

论坛徽章:
0
发表于 2011-03-24 20:27 |显示全部楼层
帮顶……

论坛徽章:
1
2015年迎新春徽章
日期:2015-03-04 09:56:11
发表于 2011-03-24 20:35 |显示全部楼层
在pc上,打印出03020100,
但是在arm小端平台上,编译器是codesourcery的arm-q3,结果不是03020100,后做实验 ...
jetking 发表于 2011-03-24 20:12



    你結果是多少?

论坛徽章:
0
发表于 2011-03-24 20:42 |显示全部楼层
字符串数组,起始地址不一定是四字节对齐的。对于ARM体系来说,如果访问的32位整数不是4字节对齐的,是会总线错误的(相对我们用的PC,不对齐仅仅是速度变慢)

论坛徽章:
0
发表于 2011-03-24 20:44 |显示全部楼层
00020100

论坛徽章:
1
射手座
日期:2013-08-21 13:11:46
发表于 2011-03-24 20:46 |显示全部楼层
uint8_t buf[]={0,1,2,3,4};
uint32_t t=(buf[0]<<0) | (buf[1]<<8 ) | (buf[2]<<16) | (buf[3]<<24);

是这样么

论坛徽章:
0
发表于 2011-03-24 21:49 |显示全部楼层
果然是牛人多

论坛徽章:
0
发表于 2011-03-25 09:24 |显示全部楼层
字符串数组,起始地址不一定是四字节对齐的。对于ARM体系来说,如果访问的32位整数不是4字节对齐的,是会总 ...
liwangli1983 发表于 2011-03-24 20:42



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

论坛徽章:
0
发表于 2011-03-25 09:26 |显示全部楼层
uint8_t buf[]={0,1,2,3,4};
uint32_t t=(buf[0]
egmkang 发表于 2011-03-24 20:46


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

论坛徽章:
0
发表于 2011-03-25 09:43 |显示全部楼层
这是不是就意味着,上述的用法,不具备移植性,在某些平台下面有陷阱,要避免。
jetking 发表于 2011-03-25 09:24



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

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP