假设 C 中的整数由硬件规范处理还是在软件中处理？答案

【问题标题】：Are integers in C assumed to be handled by a hardware spec or handled in software?假设 C 中的整数由硬件规范处理还是在软件中处理？
【发布时间】：2009-07-26 12:59:51
【问题描述】：

C 中的整数是假定由硬件规范处理还是由软件处理？

整数，我指的是原始的“int”

基本思想是，如果 C 中的整数不依赖于硬件，那么让 gcc 实现不同的整数处理程序是否违反标准。这样您就可以拥有传统的 32 位 int 处理程序，然后您还可以拥有 256 位整数的处理程序，甚至可能是动态大小的 int。

我知道 long 和 long long，但我不确定它们是否独立于提供的硬件，我只想指定构建工具链时使用的“int”处理程序的大小/类型.

我也理解这样做的危险（因为使用 32 位整数编译器构建 256 位整数会很糟糕！），但是对于那些需要 gmp 库之类的代码，我认为它会生成代码可读性好很多。兼容性将是相同的，但依赖于编译器而不是代码本身。

我知道这个想法很疯狂……但回到最初的问题：

C 中的整数是假定由硬件规范处理还是由软件处理？

【问题讨论】：

也许你想看看 C++ 及其运算符重载能力。
AFAIK，整数的大小取决于编译器编写者的想法。它们通常使 int 的大小与底层架构相匹配。
你可以放弃并使用haskell来代替程序的那些部分stackoverflow.com/questions/1184296/…我不希望有太多的性能损失，甚至可能运行得更快，具体取决于哪种类型它是程序。

标签： c math gcc standards gmp

【解决方案1】：

标准说

“普通”int 对象具有执行环境架构所建议的自然大小（大到足以包含在标题 <limits.h> 中定义的 INT_MIN 到 INT_MAX 范围内的任何值）。

并且<limits.h> 的描述约束INT_MIN 最多为-32767，INT_MAX 至少为32767。因此，如果您的硬件有一个12 位的字，则必须使用两个字来表示@ 987654328@.

【讨论】：

本质上，在内核空间中，EE 就是硬件。在用户空间中，内核是 EE。因此，int 必须是硬件对某种“EE 链”所做的自然大小。
我见过一个用于 8 位微控制器的 C 编译器使用 8 位整数。一旦您进入该空间并且可能已经在执行诸如禁止递归之类的操作，则 int 的“自然大小”特性比最小大小限制更重要。
当你遇到不符合的实现时，有很多事情。例如，我还看到了 6 位字符。 8 位整数实际上似乎比 6 位字节更奇怪，因为 8 位数据 (char) 已经是一个很好的选择，而拥有 8 位整数意味着 char、short、int 和 long 之间的双重关系，或者仅作为一种类型的 long超过 8 位。

【解决方案2】：

是的，int 将以本机大小处理。所以sizeof(int) 可能会给你一个不同的值，这取决于你编译和运行的系统。 int 的所有数学运算都将由 CPU 的本机指令处理——比在软件中执行要快得多。如果您需要 int256，则需要自己编写。而且我确信那里有任意大小的整数库。

【讨论】：

【解决方案3】：

实现 256 位 int 的 C 实现将完全符合 C 标准（但请注意，它必须使 long int 和 long long int 至少也这么长）。

但是，这种编译器生成的代码通常不与同一平台上其他编译器生成的代码链接兼容，这是实践中没有这样做的原因之一。

【讨论】：

好吧，无论如何，我认为它仅用于自定义工具链或交叉编译器类型的环境。因此，您必须将所有内容都链接起来，并使用相同的编译器规范构建。