【问题标题】:Why use anything but unions for IEEE 754 floating point format?为什么对 IEEE 754 浮点格式使用除联合之外的任何东西?
【发布时间】:2014-05-28 17:09:36
【问题描述】:

我一直在研究将浮点数(浮点数和双精度数)转换为 IEEE 754 的方法,以便创建例程以有效地跨网络连接发送/接收信息。 (类似于 perl 的打包/解包功能。)我已经通过Locklesstechnical-recipes.comBit TwiddlingBitwizardryHaskell.org (c++) 等方法了解了创建 IEEE 754 表示的方法,但我确实这样做了不明白为什么这些方法比仅仅使用联合来获得转换更快/更有效/更好?涉及整数/浮点数或长/双精度的联合转换似乎是让 C 处理符号、指数和尾数问题的更好方法,而不是手动使用移位和旋转进行。

例如,通过位旋转,您可以手动创建 IEEE 754 表示:

/* 23 bits of float fractional data */
#define I2F_FRAC_BITS   23
#define I2F_MASK ((1 << I2F_FRAC_BITS) - 1)

/* Find the log base 2 of an integer (MSB) */
int
getmsb (uint32_t word)
{
    int r;
#ifdef BUILD_64
    union { uint32_t u[2]; double d; } t;  // temp
    t.u[__FLOAT_WORD_ORDER==LITTLE_ENDIAN] = 0x43300000;
    t.u[__FLOAT_WORD_ORDER!=LITTLE_ENDIAN] = word;
    t.d -= 4503599627370496.0;
    r = (t.u[__FLOAT_WORD_ORDER==LITTLE_ENDIAN] >> 20) - 0x3FF;
#else    
    while (word >>= 1)
    {
        r++;
    }
#endif  /* BUILD_64 */
    return r;
}

/* rotate to right */
inline uint32_t 
rotr (uint32_t value, int shift)
{  return (value >> shift) | (value << (sizeof (value) * CHAR_BIT - shift));  }

/* unsigned to IEEE 754 */
uint32_t
u2ieee (uint32_t x)
{
    uint32_t msb, exponent, fraction;


    if (!x) return 0;       /* Zero is special */
    msb = getmsb (x);       /* Get location of the most significant bit */
    fraction = rotr (x, (msb - I2F_FRAC_BITS) & 0x1f) & I2F_MASK;
    exponent = (127 + msb) << I2F_FRAC_BITS;

    return fraction + exponent;
}

/* signed int to IEEE 754 */
uint32_t i2ieee (int32_t x)
{
        if (x < 0)
            return u2ieee (-x) | 0x80000000;
        return u2ieee (x);
}

此时您可以将其转换为十六进制或二进制字符串,将其放入一个数据包并在另一端反转该过程。 (注意,这只是针对 32 位的情况,64 位的数字也需要类似的功能。)为什么要这样?为什么不将浮点数或双精度数放在自动存储在 IEEE 754 表示中的联合中,然后简单地使用 int 或 long 表示?似乎所有情况都可以通过以下似乎不太容易出错的方式来处理:

union uif { int i; float f; };
union uid { long int i; double d; };

int
f2ieee (float f) {
    union uif cvt;
    cvt.f = f;
    return cvt.i;
}

float
ieee32f (int i) {
    union uif cvt;
    cvt.i = i;
    return cvt.f;
}

long
d2ieee64 (double d) {
    union uid cvt;
    cvt.d = d;
    return cvt.i;
}

double
ieee64d (long int i) {
    union uid cvt;
    cvt.i = i;
    return cvt.d;
}

所有这些都是很好的学习,但我错过了最重要的部分。为什么要以一种方式而不是另一种方式呢? 当简单地从联合中读取更不容易出错并且从表面上看似乎更有效时,手动转换提供了什么好处?专家怎么说?

【问题讨论】:

    标签: c ieee-754


    【解决方案1】:

    您建议的“更简单”代码与您建议替换的代码不同。您的代码是将机器浮点数(可能不是 IEEE 格式)转换为具有相同表示的相同大小的无符号整数的正确方法。您不喜欢的“bit-twiddling”代码是(如果我理解正确的话)手动计算具有与给定整数相同的 numeric value 的 IEEE 格式浮点数。这两种操作都很有用,但在不同的上下文中。例如,我希望在具有硬件 IEEE 浮点但没有对值进行分类的特殊指令的 CPU 上的 fpclassify 实现中看到您建议的代码,以及在软件实现中的“位旋转”代码完全没有硬件浮点的机器的浮点库。

    使用位域来提取浮点值的域是不安全的,因为 C 标准规定位域打包到 struct 中的顺序是 implementation-defined (N1570: 6.7.2.1p11),这意味着编译器可以选择他们喜欢的任何顺序。他们应该记录他们所做的事情,但他们不必选择“有意义”的排序,特别是,如果你写一个struct,其位字段对应于符号、指数和尾数字段对于 IEEE 浮点值,您可以跨平台依赖与实际 IEEE 浮点值的字段对齐的那些位字段。确实有一些编译器会按照与目标 CPU 的浮点单元所期望的方向相反的方向打包位字段。

    现在,就标准的字母而言,如果您使用位移位和掩码来提取字段,这个问题会让您更糟,因为您从浮动转换中获得的值- 指向您希望具有相同表示的相同大小的无符号整数的值是 unspecified (N1570: 6.2.6.1p7),它比实现定义的更少(但比实现定义的更多)不明确的)。但是,在实践中,这样做更有可能奏效。 (我只能想到一个完全过时的情况,它不能工作:1990 年代初期的一些基于 ARM 的系统具有第三方浮点协处理器,它们是大端的,与主 CPU 选择整数相反值。相比之下,有 几十个 编译器对位域使用“错误”排序;甚至已知它会在较小的升级时发生变化。)

    (看看 Ada 的“表示条款”,看看它真正需要什么才能让程序员能够将记录类型与内存中位排列的外部规范对齐.C 甚至没有接近。)

    (如果您只想将整数转换为具有相同 的浮点数,并且您不负责实现编译器后端,则可以通过简单的赋值来完成:@ 987654327@ 走另一条路,您可能正在寻找lrint 及其朋友。)

    【讨论】:

    • 谢谢。我并没有说我不喜欢使用位移和旋转,事实上,我非常喜欢它们以及解剖它们所带来的学习。至于主要问题,为什么一个或另一个,现在更清楚为什么我没有找到答案。我专门阅读了关于它不安全且依赖于编译器的 cmets,但对于我阅读的每一个警告,我还读到它适用于 99.9% 的现有警告,......以及另一个提取位域的例子......我的意图是使用移位/旋转创建一组干净的函数,但联合是一个诱人的分心。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2010-12-23
    • 2012-01-06
    • 2014-10-18
    • 1970-01-01
    • 2016-12-07
    • 1970-01-01
    • 2013-06-09
    相关资源
    最近更新 更多