Accounting changes

[Diomidis Spinellis]

Peter Jeremy wrote:
> On 2007-May-06 12:06:02 +0300, Diomidis Spinellis <dds at aueb.gr> 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