libjpeg中的指针对齐答案

【问题标题】：Pointer alignment in libjpeglibjpeg中的指针对齐
【发布时间】：2011-04-16 11:42:33
【问题描述】：

#define PACK_TWO_PIXELS(l,r)   ((r<<16) | l)
#define PACK_NEED_ALIGNMENT(ptr) (((int)(ptr))&3)
#define WRITE_TWO_PIXELS(addr, pixels) do {     \
         ((INT16*)(addr))[0] = (pixels);        \
         ((INT16*)(addr))[1] = (pixels)>>16;    \
    } while(0)
#define WRITE_TWO_ALIGNED_PIXELS(addr, pixels)  ((*(INT32*)(addr)) = pixels

谁能解释一下 WRITE_TWO_PIXELS 和 WRITE_TWO_ALIGNED_PIXELS 之间的区别？如果像素是分配的堆栈 uint32_t 和 addr & 3 == 0，它们不应该是等价的吗？

谢谢。

【问题讨论】：

我已经编辑了我的示例。请再检查一次。我很抱歉这个错误。

标签： c++ c pointers alignment libjpeg

【解决方案1】：

WRITE_TWO_PIXELS 和 WRITE_TWO_ALIGNED_PIXELS 对于小端机器是等价的，但对于大端架构则不是。

[示例编辑：感谢 Steve Jessop]

让，像素 = 0x0A0B0C0D

对于大端机器，WRITE_TWO_PIXELS 工作如下：

---------------------
| 0B | 0A | 0D | 0C |
---------------------
  3    2    1    0          <--- addr

WRITE_TWO_ALIGNED_PIXELS 会写如下：

---------------------
| 0D | 0C | 0B | 0A |
---------------------
  3    2    1    0          <--- addr

【讨论】：

第一个不应该是BADC吗？ (int16)pixels，即0xCD，位于较低的地址（您在右侧），(int16)(pixels>>16) 在较高的地址（您在左侧）。我可能是错的 - 右边的较低地址是我的头脑;-)
我认为你是对的。字节序是一个令人困惑的事情！我会更新我的答案。

【解决方案2】：

在这两个宏中，唯一重要的对齐是addr 的对齐。正如问题中所写，如果addr 是 32 位对齐的（意味着它的低两位为零），它们是等价的，但前提是目标架构也是 little-endian。

在大端机器上，pixels 的高 16 位必须写入(INT16*)(addr))[0]，低 16 位必须写入(INT16*)(addr))[1]，以便它们等价。

在不检查我的 libjpeg 源代码副本的情况下，我猜这些定义要么预计会作为移植库的一部分而被修改，要么它们已经被字节序声明所保护。

如果 addr 不是 32 位对齐的，那么 WRITE_TWO_ALIGNED_PIXELS 宏可能会导致在不允许未对齐访问的架构上引发异常。当然在某些情况下，未对齐访问是允许的，但比两个较小的对齐访问要昂贵得多，并且在其他一些架构上，未对齐访问很难与对齐访问区分开来。

这两个宏的存在是为了提醒库的作者考虑对齐，并标准化处理未对齐访问的方法，以便在为无关紧要的平台构建时对其进行优化。

【讨论】：

“可能会引发异常” - 更好的是，显然在某些 ARM 芯片上，未对齐的访问不会导致硬件异常，它只是默默地读取/写入错误的值。不过，我只在它陷阱的地方使用过 ARM。
@Steve Jessop，巧合的是，我刚刚帮助一位同事调试了一个数据包的一个字节不应该为零的东西。原来是由对相邻奇数地址的 16 位写入引起的，这显然是默默地向下舍入到对齐的地址，从而破坏了相邻的字段。这是在专有 SOC 的 ARM 内核中。据我们所知，没有抛出异常，并且有证据表明 read 取回了写入的值。道德是，小心任何平台上的未对齐访问，这总是是一个可移植性问题。