Date: Sun, 06 May 2007 14:43:54 +0300 From: Diomidis Spinellis <dds@aueb.gr> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: arch@freebsd.org, Garance A Drosehn <gad@freebsd.org> Subject: Re: Accounting changes Message-ID: <463DBF7A.8070200@aueb.gr> In-Reply-To: <20070506101020.GL825@turion.vk2pj.dyndns.org> References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <p06240809c262e5d7ac79@[128.113.24.47]> <463D9A7A.1080800@aueb.gr> <20070506101020.GL825@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote: > On 2007-May-06 12:06:02 +0300, Diomidis Spinellis <dds@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463DBF7A.8070200>