所以你有零扩展的半字节解压缩在big-endian顺序打包成字节？
就像strtol for hex -> integer，经过一些初始处理，将ASCII十六进制数字Map到它们表示的整数数字。
对于您想要从偶数位置打包字节的原始设置，UZP1，但您也可以优化shift/orr步骤。
而不是2x ushl + orr的第一个块，也许是shl v10.8h, v6.8h, #12/orr来获得奇数元素中想要的字节，垃圾（未修改）偶数元素。（从0开始计数，0a元素，因为我认为您正在以最低有效位优先顺序编写向量，其中较宽的左移位将数据向右移动跨越字节边界）。sli v6.8h, v6.8h, #12**（Shift-Left and Insert，其中位在左移创建零的位置保持其原始值。）

对于打包步骤，UZP2应该将奇数向量元素（从1开始）打包到低8个字节中。（如果使用相同的向量作为两个源操作数，则在高8个字节中重复。）

// produces the same result as all your code
//  in the bottom 8 bytes of v10
 sli   v6.8h, v6.8h, #12       //a0,ab,c0,cd,e0,ef,70,78, a0,ab,c0,cd,e0,0f,70,78
 uzp2  v10.16b, v6.16b, v6.16b //ab,cd,ef,78,ab,cd,0f,78, ab,cd,ef,78,ab,cd,0f,78

// rev64 v10.8b, v10.8b         // if you want a uint64_t in proper order

字符串
（我注意到你有一个e0字节。(0xe0 as u16) << 12移出位变成0，如果这不是0x0e的错别字的话）
如果这是跨半字节对的顺序，则这会使数据保持big-endian字节顺序。**在打包时，您可能需要使用字节混洗tbl或uzp2**将顺序反转为uint64_t。或者如果您一次只对一个数字执行此操作（所以加载一个shuffle-control常量需要另一条不能从循环中提升出来的指令）可能是uzp2之后的rev64 v10.8b, v10.8b。或者是rev64和v10.16b在向量的两半中做两个u64整数。
对于字节对的打包，右移和usra乘以#4的累加也可以在一条指令中完成（移位和累加），因为当设置位不重叠时，ORR、ADD和插入是等效的。但它会给你给予0xba而不是0xab，将第二个字节向下移位以成为U8.rev16 + usra的高半部分将起作用，但是shl + orr也是2个指令并且可能更便宜，可能至少在一些CPU上运行更多的执行单元。sli甚至更好，谢谢@fuz。
没有usla。乘法累加可以与2的幂乘法器一起使用，但在某些CPU上可能比shl + orr慢，并且需要一个向量常数。当然比sli更糟糕。