为什么 C99 标准的作者不指定浮点类型大小的标准？
我注意到在Windows和Linux x86上，float是4字节类型，double是8，但long double在x86和x86_64上分别是12和16。 C99 有望通过特定的整体尺寸打破此类障碍。
最初的技术限制似乎是由于 x86 处理器无法处理超过 80 位浮点运算（加上 2 个字节进行四舍五入），但为什么与 int 类型相比标准不一致？为什么他们不至少进行 80 位标准化？
I noticed on Windows and Linux x86, float is a 4-byte type, double is 8, but long double is 12 and 16 on x86 and x86_64 respectively. C99 is supposed to be breaking such barriers with the specific integral sizes.
The initial technological limitation appears to be due to the x86 processor not being able to handle more than 80-bit floating point operations (plus 2 bytes to round it up) but why the inconsistency in the standard compared to int types? Why don't they go at least to 80-bit standardization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
C语言没有指定各种类型的实现，因此它可以在尽可能广泛的硬件上有效地实现。
这也扩展到整数类型 - C 标准整数类型具有最小范围（例如，
signed char为 -127 到 127，short和int均为 -32,767 到 32,767，long为 -2,147,483,647 到 2,147,483,647，long long为 -9,223,372,036,854,775,807 到 9,223,372,036,854,775， 807）。对于几乎所有目的，这就是程序员需要知道的全部内容。C99 确实提供了“固定宽度”整数类型，例如
int32_t- 但这些是可选 - 如果实现无法有效地提供此类类型，则它没有提供它。对于浮点类型，有等效的限制（例如，
double必须具有至少 10 位十进制数字的精度）。The C language doesn't specify the implementation of various types, so that it can be efficiently implemented on as wide a variety of hardware as possible.
This extends to the integer types too - the C standard integral types have minimum ranges (eg.
signed charis -127 to 127,shortandintare both -32,767 to 32,767,longis -2,147,483,647 to 2,147,483,647, andlong longis -9,223,372,036,854,775,807 to 9,223,372,036,854,775,807). For almost all purposes, this is all that the programmer needs to know.C99 does provide "fixed-width" integer types, like
int32_t- but these are optional - if the implementation can't provide such a type efficiently, it doesn't have to provide it.For floating point types, there are equivalent limits (eg
doublemust have at least 10 decimal digits worth of precision).他们试图（主要）适应预先存在的 C 实现，其中一些甚至不使用 IEEE 浮点格式。
They were trying to (mostly) accommodate pre-existing C implementations, some of which don't even use IEEE floating point formats.
int可用于表示抽象事物，如 ID、颜色、错误代码、请求等。在这种情况下，int并不是真正用作整数，而是用作集合位（= 容器）。大多数时候，程序员确切地知道他需要多少位，因此他希望能够根据需要使用尽可能多的位。另一方面，浮点是为非常特定的用途（浮点运算）而设计的。您不太可能精确地确定
float需要多少位。事实上，大多数时候你拥有的比特越多越好。
ints can be used to represent abstract things like ids, colors, error code, requests, etc. In this caseints are not really used as integers numbers but as sets of bits (= a container). Most of the time a programmer knows exactly how many bits he needs, so he wants to be able to use just as many bits as needed.floats on the other hand are design for a very specific usage (floating point arithmetic). You are very unlikely to be able to size precisely how many bits you need for yourfloat.Actually, most of the time the more bits you have the better it is.
不，那些固定宽度的
(u)intN_t类型完全是可选，因为并非所有处理器都使用 2 的幂的类型大小。C99 仅要求(u)int_fastN _t和(u)int_leastN_t待定义。这意味着为什么标准与 int 类型不一致的前提是完全错误的，因为 int 类型的大小没有一致性。许多现代 DSP 对 24 位音频使用 24 位字。甚至还有 20 位 DSP，例如 Zoran ZR3800x 系列 或 < a href="https://www.analog.com/media/en/technical-documentation/data-sheets/ADAU1701.pdf" rel="nofollow noreferrer">28 位 DSP，例如 ADAU1701 允许在不削波的情况下转换 16/24 位音频。许多 32 位或 64 位架构还具有一些奇数大小的寄存器，以允许累积值而不会溢出，例如 TI C5500/C6000 与 40 位
长和 SHARC 带有 80 位累加器。 Motorola DSP5600x/3xx 系列 也有奇怪的大小：2 字节短， 3 字节 int，6 字节长。过去有很多架构具有其他字号，例如 12、18、 36 位、60 位...以及许多使用符号量补码的 CPU。请参阅标准委员会关心的奇异架构C 被设计为灵活以支持各种类型这样的平台。指定固定大小，无论是整数还是浮点类型，都达不到这个目的。就像整数支持一样，硬件中的浮点支持也有很大差异。有不同的格式使用十进制、十六进制或可能的其他基数。每种格式都有不同的指数/尾数大小、不同的符号/指数/尾数位置，甚至有符号格式。例如，有些使用二进制补码作为尾数，而另一些使用二进制补码作为指数或整个浮点值。您可以在此处看到多种格式，但这显然不是所有存在的格式。例如上面的 SHARC 具有特殊的 40 位浮点格式。某些平台还使用 双精度算术 进行
长双精度。另请参阅这意味着您无法为所有平台标准化单一浮点格式，因为没有一个 -适合所有人的解决方案。如果您正在设计 DSP，那么显然您需要一种最适合您用途的格式，以便您可以搅动尽可能多的数据。当 40 位格式对您的应用程序具有足够的精度、更适合缓存并且需要的芯片尺寸小得多时，没有理由使用 IEEE-754 二进制 64。或者，如果您使用的是小型嵌入式系统，则 80 位
long double通常是无用的，因为您甚至没有足够的 ROM 用于该 80 位long double库。这就是为什么某些平台将long double限制为 64 位，例如doubleNo, those fixed-width
(u)intN_ttypes are completely optional because not all processors use type sizes that are a power of 2. C99 only requires that(u)int_fastN_tand(u)int_leastN_tto be defined. That means the premise why the inconsistency in the standard compared to int types is just plain wrong because there's no consistency in the size of int typesLots of modern DSPs use 24-bit word for 24-bit audio. There are even 20-bit DSPs like the Zoran ZR3800x family or 28-bit DSPs like the ADAU1701 which allows transformation of 16/24-bit audio without clipping. Many 32 or 64-bit architectures also have some odd-sized registers to allow accumulation of values without overflow, for example the TI C5500/C6000 with 40-bit
longand SHARC with 80-bit accumulator. The Motorola DSP5600x/3xx series also has odd sizes: 2-byte short, 3-byte int, 6-byte long. In the past there were lots of architectures with other word sizes like 12, 18, 36, 60-bit... and lots of CPUs that use one's complement of sign-magnitude. See Exotic architectures the standards committees care aboutC was designed to be flexible to support all kinds of such platforms. Specifying a fixed size, whether for integer or floating-point types, defeats that purpose. Floating-point support in hardware varies wildly just like integer support. There are different formats that use decimal, hexadecimal or possibly other bases. Each format has different sizes of exponent/mantissa, different position of sign/exponent/mantissa and even the signed format. For example some use two's complement for the mantissa while some others use two's complement for the exponent or the whole floating-point value. You can see many formats here but that's obviously not every format that ever existed. For example the SHARC above has a special 40-bit floating-point format. Some platforms also use double-double arithmetic for
long double. See alsoThat means you can't standardize a single floating-point format for all platforms because there's no one-size-fits-all solution. If you're designing a DSP then obviously you need to have a format that's best for your purpose so that you can churn as most data as possible. There's no reason to use IEEE-754 binary64 when a 40-bit format has enough precision for your application, fits better in cache and needs far less die size. Or if you're on a small embedded system then 80-bit
long doubleis usually useless as you don't even have enough ROM for that 80-bitlong doublelibrary. That's why some platforms limitlong doubleto 64-bit likedouble