为什么 C99 标准的作者不指定浮点类型大小的标准？

发布于 09-13 18:32 字数 207 浏览 20 评论 0原文

我注意到在Windows和Linux x86上，float是4字节类型，double是8，但long double在x86和x86_64上分别是12和16。 C99 有望通过特定的整体尺寸打破此类障碍。

最初的技术限制似乎是由于 x86 处理器无法处理超过 80 位浮点运算（加上 2 个字节进行四舍五入），但为什么与 int 类型相比标准不一致？为什么他们不至少进行 80 位标准化？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦初启2024-09-20 18:32:17

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 位十进制数字的精度）。

回复收藏 0 原文

宛菡2024-09-20 18:32:17

他们试图（主要）适应预先存在的 C 实现，其中一些甚至不使用 IEEE 浮点格式。

回复收藏 0 原文

向地狱狂奔2024-09-20 18:32:17

int 可用于表示抽象事物，如 ID、颜色、错误代码、请求等。在这种情况下，int 并不是真正用作整数，而是用作集合位（= 容器）。大多数时候，程序员确切地知道他需要多少位，因此他希望能够根据需要使用尽可能多的位。

另一方面，浮点是为非常特定的用途（浮点运算）而设计的。您不太可能精确地确定 float 需要多少位。
事实上，大多数时候你拥有的比特越多越好。

回复收藏 0 原文

东风软2024-09-20 18:32:17

C99 应该通过特定的整数大小来打破这些障碍。

不，那些固定宽度的(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 位，例如 double

C99 is supposed to be breaking such barriers with the specific integral sizes.

No, those fixed-width (u)intN_t types are completely optional because not all processors use type sizes that are a power of 2. C99 only requires that (u)int_fastN_t and (u)int_leastN_t to 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 types

Lots 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 long and 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 about

C 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 also

That 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 double is usually useless as you don't even have enough ROM for that 80-bit long double library. That's why some platforms limit long double to 64-bit like double

回复收藏 0 原文

~没有更多了~