在16位微处理器上，我应该使用数据类型short而不是int吗？

Question

我已经读过使用short vs int实际上为编译器创建了一个低效率，因为它需要使用int数据类型，而不管C整数提升。这对16位微处理器是否正确？

另一个问题：如果我有一个1和0的数组，那么在这个16位微处理器中使用uint8_t或unsigned char是否最有效？或者它仍然存在转换回int的问题..

请帮我澄清这个泥泞的问题。谢谢！

Answer 1

1. 真的是个问题吗？在我听说过的大多数16位系统中，int和short最终都是相同的大小（16位），所以在实践中应该没有什么区别。

   < / LI>

2. 如果系统中存在uint8_t，则它将与unsigned char同义。 unsigned char将是系统上可用的最小无符号类型。如果它超过8位，则不会有uint8_t。如果它小于8位，那么它违反了标准。没有效率差异，因为必须根据另一个来定义。

最后，你真的需要担心这些微观差异吗？如果你这样做，你需要查看装配输出或（更可能）配置文件，看看哪一个更快。

Answer 2

在16位或更大的处理器上，如果您不关心将占用多少存储空间，请使用“int”而不是“short”或“signed char”。如果您不关心存储要求或包装行为，请使用'unsigned int'而不是'unsigned short'或'unsigned char'。在8位处理器上，'char'类型可能比'int'更快，但在16位和更大的处理器上，16位数学比32位数学更快，'int'可能是16位所以没有必要使用'short'或'char'来提高速度。

BTW，在某些处理器上，'unsigned short'比'unsigned int'慢得多，因为C标准要求对无符号类型'wrap'进行操作。如果无符号短变量“foo”存储在寄存器中，则典型的ARM编译器生成“foo + = 1;”的代码。将生成一条指令来执行增量，并将两条指令截断为65535 [BTW，一个优化编译器，注意'foo'永远不会超过65536可能会刮一条指令，但我不知道是否有任何真正的编译器会]。签名的'short'不必比'signed int'慢，因为标准不强制截断;我不确定是否有任何编译器会跳过对已签名类型的截断。

Answer 3

在Blackfin上，32位或16位类型通常会产生更高的性能可能不是一个简单的答案，因为它支持16,32和64位指令，并且有两个16位MAC。它取决于操作，但我建议你相信你的编译器优化器做出这样的决定，它比你可能关心的更多地了解处理器的指令时序和调度。

那说可能是你的编译器int和short在任何情况下都是相同的大小。查阅文档，使用sizeof进行测试，或在limits.h标题中查找将推断宽度或各种类型的数值范围。

如果您确实要限制数据类型大小，请使用stdint.h类型，例如int16_t。

stdint.h还定义fastest minimum-width integer types，例如int_fast16_t，这将保证最小宽度，但如果目标上的速度更快，则会使用更大的类型。这可能是解决问题的最便携方式，但它依赖于实现者对要使用的适当类型做出了很好的决策。在大多数架构上，它几乎没有差别，但在RISC和DSP架构上可能并非如此。也许情况并非如此，特定尺寸在所有情况下都是最快的，对于Blackfin来说尤其如此。

在某些情况下（大量数据从外部存储器传输），最快的大小可能是与数据总线宽度匹配的大小。

Answer 4