4

我已经读过，使用shortvs实际上会为编译器造成效率低下，因为无论由于 C 整数提升int，它都需要使用数据类型。int这对 16 位微处理器来说是真的吗？

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

请帮我清理一下我脑海中的这个泥泞问题。谢谢！

4

4 回答 4

5

  1. 这真的是一个问题吗？在我听说过的大多数 16 位系统上，int最终short大小相同（16 位），因此在实践中应该没有区别。

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

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

于 2011-02-14T20:07:21.910 回答
2

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

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

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

stdint.h还定义了最快的最小宽度整数类型，例如int_fast16_t，这将保证最小宽度，但如果它在您的目标上更快，则会使用更大的类型。这可能是解决您的问题的最便携的方法，但它依赖于实现者对要使用的适当类型做出正确的决定。在大多数架构上它几乎没有区别，但在 RISC 和 DSP 架构上可能并非如此。也可能不是特定尺寸在所有情况下都是最快的，在 Blackfin 的情况下可能尤其如此。

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

于 2011-02-14T20:27:15.623 回答
2

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

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

于 2011-02-14T20:07:49.063 回答
0

我强调在依赖字节大小的项目中有一个看起来像这样的块：

typedef uint8 char
typedef uint16 short
typedef uint32 long

适用于任何数据类型。

任何转换问题都应该在编译时解决。这些将取决于 cpu 和编译器。

当然，在 16 位 CPU 上添加 2 个 32 位数字将需要编译器进行一些处理。当你从内存中加载时也会有一些有趣的事情，这取决于内存字宽以及你是否可以从任何地址加载，或者是否必须从给定的边界加载字节

在short, YMMV 中，并在 profiling 后进行优化。

于 2011-02-14T20:12:20.247 回答