Re: Accounting changes
- From: Diomidis Spinellis <dds@xxxxxxx>
- Date: Sun, 06 May 2007 14:43:54 +0300
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 theMy 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.
native-hardware format for floating point numbers? Does that mean
the records produced will be different for different hardware?
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
- 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
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"
- Re: Accounting changes
- From: Erik Trulsson
- Re: Accounting changes
- Prev by Date: Re: HEADS DOWN
- Next by Date: Re: Accounting changes
- Previous by thread: Re: Accounting changes
- Next by thread: Re: Accounting changes