hagopiar@vuser.vu.union.edu  wrote on 01.06.99 in <Pine.LNX.4.10.9906011723020.6925-100000@sequoia.hagopian.net>:

> Sure, it would be nice, but so would a 128-bit value. That would solve
> time problems for quite a while, but it's just not practical. That's why
> Sun went the way of fixing it for 64-bit machines and letting the 32-bit
> machines fall to the wayside.

Well, let's see what you'd want to have for the long run.

You want to be able to cover a range of around 100e9 years (several times  
the current age of the universe), in seconds that's approximately 61 bits.  
And for resolution, you probably want at least nanoseconds (that's only 1  
GHz, in a few years cycle counters will probably run faster than that),  
that's 1e9 or about 30 bits.

91 bit together, might as well use 96 (64+32).

2^64 seconds are over 500e9 years (better use 250 signed), and 1/2^32  
seconds are about a quarter nanosecond. Sounds about right.

Now, that's for the interface. What's used internally is a completely  
different question.

MfG Kai

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/