From owner-freebsd-arch Fri Oct 26 10:30:12 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id C28AD37B406 for ; Fri, 26 Oct 2001 10:30:06 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f9QHTuJ56180; Fri, 26 Oct 2001 13:29:59 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200110260047.f9Q0lsf16513@apollo.backplane.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com> Date: Fri, 26 Oct 2001 13:29:53 -0400 To: Matthew Dillon , Poul-Henning Kamp From: Garance A Drosihn Subject: Re: 64 bit times revisited.. Cc: Peter Wemm , arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 5:47 PM -0700 10/25/01, Matthew Dillon wrote: >:I vote for option (3), 64-bit time_t for all 64 bit architectures. >:I would go along with option (4) provided that the change-over came >:with FreeBSD 5.0 and it was not MFC'ed back to the 4.X series. > > I agree completely. 64 bit time_t for all 64 bit archs, and > frankly I would also like to see a 64 bit time_t for 5.x on 32 > bit archs... lets get the pain over and done with now rather > then later. Let me waste a few electrons by also agreeing to this general direction. We are hoping to bring on new platforms of sparc64 and ia-64 for the 5.0-timeframe (or certainly before the 6.0 timeframe). It would be exceedingly stupid to start out those 64-bit platforms on 32-bit time_t's, when we KNOW we will have switch to 64-bit times at some later point. So, I would put in a very strong, pound-the-table vote for 64-bit time_t on 64-bit architectures. Given 64-bit time_t's for the new platforms, we might as well go for 64-bit times on all platforms (although we obviously can not MFC that back into the 4.x-branch for 32-bit platforms). I don't feel quite so strongly about 64-bit time_t's on 32-bit architectures, but it does seem like the right thing to do. I don't have any strong feelings on the specifics of how we get to 64-bit time_t's. I do think the following suggestion seems like a worthwhile idea, but maybe I am unaware of some reason that it would be a problem. At 8:28 AM +0200, Poul-Henning Kamp wrote: >I would like for us to introduce a new format of timestamps: > > struct time$something { > time_t tx_sec; /* 64bit */ > uint_64_t tx_fsec; /* binary fraction of second */; > } > >If we have access to a int_128_t type, we could instead simply >define a scalar type 128 bits wide, resolved in 1/(1<<64) seconds >(.0542E-18 == .0542 attoseconds) > >This format would be faster for any kind of arithmetic, including >inside the timecounter code, and it would have sufficient bits in >both directions for any forseeable future. So, I'll also add a vote towards that idea, although it might be easy to convince me that some other idea would much better. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message