From owner-freebsd-arch@FreeBSD.ORG Sun May 6 11:44:06 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D790516A402; Sun, 6 May 2007 11:44:06 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.103]) by mx1.freebsd.org (Postfix) with ESMTP id 5221E13C45E; Sun, 6 May 2007 11:44:06 +0000 (UTC) (envelope-from dds@aueb.gr) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id l46Bi4s0023419; Sun, 6 May 2007 14:44:04 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46Bi4tq024566; Sun, 6 May 2007 14:44:04 +0300 Received: from [192.168.136.22] (ppp124-213.adsl.forthnet.gr [193.92.231.213]) by MX-IN-02.forthnet.gr (8.14.1/8.14.1) with ESMTP id l46BhvCV000353; Sun, 6 May 2007 14:43:57 +0300 Authentication-Results: MX-IN-02.forthnet.gr from=dds@aueb.gr; sender-id=neutral; spf=neutral Message-ID: <463DBF7A.8070200@aueb.gr> Date: Sun, 06 May 2007 14:43:54 +0300 From: Diomidis Spinellis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Peter Jeremy References: <19235.1178303887@critter.freebsd.dk> <463BB88F.4020804@aueb.gr> <463D9A7A.1080800@aueb.gr> <20070506101020.GL825@turion.vk2pj.dyndns.org> In-Reply-To: <20070506101020.GL825@turion.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Garance A Drosehn Subject: Re: Accounting changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2007 11:44:06 -0000 Peter Jeremy wrote: > On 2007-May-06 12:06:02 +0300, Diomidis Spinellis 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