在 64 位 RISC-V 上，当 32 位操作数加载到寄存器中时，有必要决定是符号扩展还是零扩展到 64 位，并且架构决定更喜欢前者，大概是因为 C 家族语言中最常见的 int 类型是有符号的 32 位整数。所以符号扩展比零扩展略快。
8 位操作数也一样吗？换句话说，signed char 是否比unsigned char 更高效？
【问题讨论】：
标签： riscv
如果您要将大量 8 位值扩展到 wchar_t，unsigned char 就是您想要的，因为这是一个空操作而不是位掩码。如果您的 char 格式是 UTF-8，您还希望能够使用无符号数学进行轮班。如果您正在使用库函数，那么使用您的库所期望的类型最为方便。
The RISC-V architecture has 包括将符号扩展的 8 位值加载到寄存器中的 LB 指令和零扩展的 LBU 指令。两者都同样有效。在 C 中，算术运算中使用的任何 signed char 都被扩展为 int，并且 C 标准库函数指定将 char 扩展为 int，因此这会将变量置于正确的格式中以供使用。
存储是一个截断问题，从任何整数类型转换为unsigned char 是微不足道的（0xff 的位掩码）。从unsigned char 转换为有符号值可以在不超过两条指令中完成，无需条件或寄存器压力（SLLI 将char 的符号位放入机器寄存器的符号位，然后SRLI 对高位进行符号扩展）。
因此，在此架构中使用任何一种都不会产生额外的开销。 API 指定符号扩展而不是符号数量的零扩展。
顺便说一句，RV64I 在架构上并不喜欢符号扩展。那是the ABI convention，但指令集添加了一条LWU 指令以从具有零扩展的内存中加载一个32 位值和一个可以对零扩展的32 位结果进行符号扩展的ADDIW。 （没有对应的ADDIB 8 位或ADDIH 16 位数量。）
【讨论】：