Re: Accounting changes

Peter Jeremy wrote:
On 2007-May-06 12:06:02 +0300, Diomidis Spinellis <dds@xxxxxxx> wrote:
Garance A Drosehn wrote:
Does this mean the new accounting record will be using the
native-hardware format for floating point numbers? Does that mean
the records produced will be different for different hardware?
My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC 60559) 32-bit float format. This is the C "float" type on all the architectures we support. I could add a typedef clarifying this, but I doubt we'll ever support an architecture (VAX?) where float is a different format.

IEEE-754 etc define how to interpret a 32-bit object as a floating
point number. AFAIK, it does not define how that object is laid
out in memory so that a float written on SPARC (big-endian) will
be different to that written on an i386 (little-endian).

IEEE-754 defines the order of bits in a number. The intention is to allow lexicographical comparison of (valid) floating point numbers, using the normal byte compare instructions. If you write a file with a float on a SPARC you can read it back correctly on an i386. However, given that the accounting record structure's layout differs between architectures, even this property is not something we depend on.

Accounting records do not need all the features that a general FP
format needs:
- No need to support negative numbers
- It is easy to define comp_t so there are no negative exponents
- No need to support denormals
- No need to support NaN
- Supporting infinity is optional.

This means that it's possible to define a format that is relatively
easy to manipulate or convert into a "standard" C FP format.

True, IEEE numbers provide more features than we need. At the kernel interface where we write them, the conversion routine simply doesn't support these features, because, as you correctly say, we don't need them. At the userland interface (lastcomm, sa) these features are provided at no cost by the processor hardware and the C library.

By adopting IEEE 754 we waste the storage space of the bit used to indicate negative numbers. However, I find that the benefit of not introducing another format (phk complained about that), and being able to read the records into standard C floats outweighs this loss.

Diomidis Spinellis - http://www.spinellis.gr
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Science & Business of Floating-Point Numbers
    ... The 128 bit format just added ... It's been maintained to this day, but now the machines support 128 bit ... I don't believe any of the others mentioned ever had hardware 128-bit ...
    (comp.arch)
  • Re: [9fans] audio standards -- too many to choose from
    ... made -- pick a most common format and stick with it. ... transfers to the audio hardware buffer require ADPCM. ... The software driver had to perform the mixing before ... At least someone has the potential to add such support. ...
    (comp.os.plan9)
  • Re: Output Pin Custom Allocator
    ... is started it attempts to reagree format with upstream filter via ... you don't support ARGB32. ... renderer can revert to GDI rendering, so it first connects with a media ... then it switches to a hardware accelerated surface after you run the ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: short float ???
    ... you mention that "this format is used in the NVIDIA graphic cards, ... floatingpoint" format natively? ... we now have two competing hardware definitions for a "short float". ...
    (comp.std.c)
  • Re: short float ???
    ... you mention that "this format is used in the NVIDIA graphic cards, ... floatingpoint" format natively? ... Although those specific platforms are fairly popular, ... float", or will standard promotion rules apply and computations be ...
    (comp.std.c)