查看 AVX2 内在函数文档，那里收集了加载指令，例如 VPGATHERDD：
__m128i _mm_i32gather_epi32 (int const * base, __m128i index, const int scale);
从文档中我不清楚的是计算的加载地址是 element 地址还是 byte 地址，即元素 @ 的加载地址987654324@:
load_addr = base + index[i] * scale; // (1) element addressing ?
或：
load_addr = (char *)base + index[i] * scale; // (2) byte addressing ?
从Intel docs 看来，它可能是 (2)，但这并没有多大意义，因为收集负载的最小元素大小是 32 位 - 为什么要从未对齐的地址加载（即使用比例
【问题讨论】：
为什么要从未对齐的地址加载（即使用比例
未对齐的负载不是缩放
支持这个用例是英特尔设计 asm 指令来支持这个用例的一个原因，因为收集应该帮助编译器自动矢量化更多代码。它也很自然地适合 VSIB 字节在机器代码编码中非常接近 SIB，但它们可以很容易地预先偏置比例因子，让您选择比例 = 4、8、16、32（或 8 ,16,32,64 用于 qword 集合）具有 2 位比例字段。
在许多情况下，比元素大小更大的比例因子显然也不是很有用，并且很容易在聚集之前使用单个左移指令来模拟。但是不可能解决内置的比例因子，因此允许未缩放的索引显然是更灵活的设计选择。
其他用例：收集 16 位元素。使用 32 位聚集并在聚集后屏蔽每个元素的上半部分。 （或者只是让它拿着垃圾）。如果您的任何索引都是奇数（比例因子为 2），这将导致负载未对齐，因此如果它们跨越 4k 边界（与真正的 16 位聚集不同），它可能会很慢。
您还可以想象使用聚集作为解压缩函数的一部分，在经过一些解码后，您有一个偏移向量到缓冲区，并且您需要任意 4 字节或 8 字节的数据窗口。
【讨论】：
收集说明没有任何对齐要求。所以不允许字节寻址就太严格了。
其他原因是一致性。使用 SIB 寻址，我们显然有 byte 地址：
MOV eax, [rcx + rdx * 2]
由于VPGATHERDD 只是这条MOV 指令的向量化变体，我们不应该期望VSIB 寻址有什么不同：
VPGATHERDD ymm0, [rcx + ymm2 * 2], ymm3
对于 byte 寻址的实际用途，我们可以有一个 24 位彩色图像，其中每个像素都是 3 字节对齐的。我们可以使用单个 VPGATHERDD 指令加载 8 个像素，但前提是 VSIB 中的“scale”字段为“1”并且VPGATHERDD 使用 byte 寻址。
【讨论】：
从英特尔AVX programming reference document available here 中的描述来看，收集指令似乎使用字节寻址。具体来说，请参阅VPGATHERDD 指令描述中的以下引用（第 389 页）：
DISP: optional 1, 2, 4 byte displacement; DATA_ADDR = BASE_ADDR + (SignExtend(VINDEX[i+31:i])*SCALE + DISP;
由于您可以使用 1/2/4 字节位移，我会假设整个内存地址是一个字节地址。虽然它可能不是一个常见的应用程序，但在某些情况下，您可能希望从未对齐的地址中读取 32 位或 64 位值。与 ARM 相比，这是 x86 架构更灵活的事情之一。如果需要，您可以灵活地执行未对齐的访问，而不是像其他人那样触发 CPU 异常。
【讨论】：