我也来孔乙己，出道小题

发表于 2008-4-6 22:59

u08 buf[16];
void main( void )
{
  u32 var;
  u08 *pbuf;
  u32 *ptr;
  u32 i;

  pbuf = (u08*)((u32)(buf +4) & (~3L));
  for(i = 0; i < sizeof(buf) - 4; i++)
     pbuf = i;
  ptr = (u32*)(pbuf + 3);
  var = *ptr;
    //执行到此var的值是多少？
}
假设u08为8位无符号整形数，u16为16位无符号整形数，u32为32位无符号整形数，测试的平台均为little endia处理器，请回答
在下列平台下，var的值是多少？
1. x86架构PC机
2. 32位的嵌入式little endia处理器
3. 16位的嵌入式little endia处理器
4. 8位的嵌入式处理器

这是一道讨论题，你可以把你认为正确的答案及理由都写出来。

发表于 2008-4-7 10:08

发表于 2008-4-7 14:00

发表于 2008-4-7 14:23

ARM下会出异常吧。没实测。

发表于 2008-4-7 20:41

不仅仅是compiler 的问题。32bit 的 x86 因为历史兼容关系（兼容8088, 8086, 80386, 80486...)，可以access 8bit, 16-bit 数据，若不对齐，只是多出一次存取而已。ptr = (u32*)(pbuf + 3), ptr 的地址可以是 pbuf+3.

但很多其他的 16-bit, 32-bit cpu，16bit, 32bit 无法被分割，即必须对齐，这时 ptr = (u32*)(pbuf + 3)，ptr 的地址是 pbuf 或者是(u32*)pbuf +3 (这里的u08 实际上是 32-bit, 因为此cpu 没有8bit的内部register, char 被当作32bit 处理) , 或者compiler直接给出编译警告或错误.

发表于 2008-4-7 22:21

楼上基本解释到要点。
arm，msp430， c6000硬件都不能捕获这个异常。
上面的代码完全符合c标准，编译器不会报错，某些软件模拟器在单步的情况下能检测到。

我也来孔乙己，出道小题

相关帖子

其实就是考编译器数据类型转换的问题

这个题也不是那么简单的．

Re

alignment。 这是cpu 对齐方式的不同

从我用过的处理器来说，硬件还不能产生异常

浏览过的版块

希望之星奖章

涓涓之细流

常驻人口

技术高手奖章

荣誉元老奖章

坚毅之洋流

十世金身

技术领袖奖章

以坛为家

精英会员奖章

奔腾之江水

alignment。这是cpu 对齐方式的不同