(注意,在 Neon 中我使用 this data type 来避免处理 16 位数据类型之间的转换)
为什么内在函数中的“左移”实际上是“右移”?
// Values contained in a
// 141 138 145 147 144 140 147 153 154 147 149 146 155 152 147 152
b = vshlq_n_u32(a,8);
// Values contained in b
// 0 141 138 145 0 144 140 147 0 154 147 149 0 155 152 147
b = vshrq_n_u32(a,8);
// Values contained in b
// 138 145 147 0 140 147 153 0 147 149 146 0 152 147 152 0
我记得在使用 _mm_slli_si128
时发现了相同的情况(虽然不同,转换后的结果如下所示:
// b = _mm_slli_si128(a,1);
// 0 141 138 145 147 144 140 147 153 154 147 149 146 155 152 147
是因为字节顺序吗? 它会因平台而异吗?
最佳答案
你说“这是因为字节顺序”,但它更像是一种类型滥用。您正在假设机器跨字节/字边界的位顺序以及对操作施加本地字节序的非字节指令(您正在使用 _u32 指令,该指令期望值是无符号的 32 位值,而不是数组8 位值)。
正如您所说,您要求它通过/asking/it to shift values in 32 bit units 来移动一系列 unsigned char 值。
不幸的是,如果您希望能够对它们进行架构转换,则需要将它们按架构顺序排列。
否则,您可能想要寻找 blit 或移动指令,但您不能在不支付体系结构成本的情况下人为地将机器类型强制转换为机器寄存器。 Endianness 将只是您头疼的问题之一(对齐、填充等)
--- 后期编辑---
从根本上说,您混淆了字节移位和位移位,我们认为最重要的位是“左”的
bit number
87654321
hex
8421
00008421
00000001 = 0x01 (small, less significant)
10000000 = 0x80 (large, more significant)
但是您要移动的值是 32 位字,在小端机器上,这意味着对于 32 位字,每个后续地址都会增加该值的一个更重要的字节:
bit numbers
1111111111111111
87654321fedcba0987654321fedcba09
表示32位值0x0001
1111111111111111
87654321fedcba0987654321fedcba09
00000001000000000000000000000000
将它向左移动 2 个位置
00000001000000000000000000000000
v<
00000100000000000000000000000000
要将它向左移动另外 8 个位置,我们必须将它扭曲到下一个地址:
00000100000000000000000000000000
>>>>>>>v
00000000000001000000000000000000
如果您以字节为单位考虑,这看起来像是一个右移。但是我们告诉这个小端 CPU 我们正在处理一个 uint32,所以这意味着:
1111111111111111
87654321fedcba0987654321fedcba09
word01 word02 word03 word04
00000001000000000000000000000000 = 0x0001
00000100000000000000000000000000 = 0x0004
00000000000001000000000000000000 = 0x0400
问题是这与您期望的 8 位值本地数组的顺序不同,但您告诉 CPU 值是 _u32,所以它使用它的 native 字节顺序进行操作。
关于c++ - 为什么在实践中向右移动在 Neon 和 SSE 中向左移动(反之亦然)?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/29209004/