c - 是否可以对多个连续的数组元素进行按位运算？

Question

我正在研究几年前编写的AES的一个旧实现，我想修改ShiftRows函数，这个函数效率很低。
目前，我的ShiftRows基本上只是交换连续数组元素（由一个字节表示）的值n次来实现循环置换。
我想知道是否有可能把我的元素数组作为一个变量来使用位移运算符进行置换？
这些行是4个无符号字符，所以每行4个字节。
在下面的代码中，只有第一个字节（对应于“a”）似乎受位移的影响。

char array[4][4] = {"abcd", "efgh", "ijkl", "mnop"};

int32_t somevar;

somevar = (int32_t)*array[0] >> 16;

我很久没有练习C了，所以我可能犯了一些愚蠢的错误。

Answer 1

首先，如果您的主要目标是一个快速的AES实现，而不是实践C或者一个快速但可移植的AES实现（即，可移植性是主要的，效率是次要的），那么您需要用汇编语言而不是C编写，或者至少对允许您编写接近汇编代码的特定目标使用编译器功能。例如，Intel processors have AES-assist instructions, and GCC has built-in functions for them。
其次，如果要用C语言来实现，理想情况下，您的主要工作是向编译器清楚地表达所需的操作。我的意思是，您希望操作对编译器透明，以便其优化器可以工作。使用各种技术重新解释数据（例如从char到int）可能会阻碍编译器的优化能力。（或者它们可能不会，这取决于编译器的质量和您编写的特定代码。）
如果您的目标是可移植代码，那么最好简单地编写所需的字符运动（只需编写移动数组元素的简单赋值语句）。如果硬件支持，好的编译器甚至可以将多字节移动操作组合成单字移动操作，从而高效地转换这些操作。
当您编写“花哨的”代码以尝试优化时，重要的是要了解标准C的规则、正在使用的编译器的属性以及要瞄准的硬件。
例如，您有char array[4][4]。这声明了一个没有特定对齐方式的数组。编译器可能会将这个数组放在任何地方，例如，通过任何对齐方式，它不一定与四个字节的倍数对齐。如果随后将指向该数组第一行的指针转换为指向int的指针，则加载int的指令在某些处理器上可能会失败，因为它们要求将int对象对齐为4字节的倍数。在其他处理器上，加载可能工作，但比对齐加载慢。
一种解决方案是不声明裸数组，也不转换指针。相反，您可以声明一个联合，其中一个成员可以是一个4uint32_t的数组，另一个成员可以是一个4uint8_t的数组。联合体中uint32_t数组的存在将迫使编译器针对硬件对其进行适当的对齐。另外，在C中允许通过联合重新解释数据，而通过转换的指针重新解释数据不是正确的C代码。（即使满足对齐要求，通过指针重新解释数据通常也会违反别名规则。）
另一方面，在处理位时，通常最好使用无符号类型，就像在加密代码中那样。与char和int32_t不同，使用uint8_t和uint32_t可能会更好。
关于您的特定代码：

somevar = (int32_t)*array[0] >> 16;

array[0]是 array的第一行。根据C的规则，它被自动转换为指向其第一个元素的指针，因此它变为 &array[0][0]。然后 *array[0]是 *&array[0][0]，这是 array[0][0]，这是数组第一行中的第一个 char。所以到目前为止，表达式只是第一个 char的值。然后cast (int32_t)将表达式的类型转换为 int32_t。这不会更改值，因此结果只是第一行中第一个 char的值。
你可能想到的是 * (uint32_t *) &array[0]或 * (uint32_t) array[0]。它们接受第一行的地址（前一个表达式）或第一行的第一个元素的地址（后一个表达式）（它们表示相同的位置，但类型不同）并将其转换为指向a uint32_t的指针。然后 *将在该地址获取 uint32_t。这违反了C规则，应该避免。
相反，您可以使用：

union
{
    uint32_t words[4];
    uint8_t  bytes[4][4];
} block;

然后，您可以使用 block.bytes[i][j]访问单个字节，或使用 block.words[i]访问四个字节的单词。这是否是一个好主意取决于环境和目标。