Date: Fri, 26 Oct 2001 13:29:53 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Matthew Dillon <dillon@apollo.backplane.com>, Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Peter Wemm <peter@wemm.org>, arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <p0510101ab7ff49f3b996@[128.113.24.47]> In-Reply-To: <200110260047.f9Q0lsf16513@apollo.backplane.com> References: <200110260006.f9Q05vQ05273@beastie.mckusick.com> <200110260047.f9Q0lsf16513@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p0510101ab7ff49f3b996>