On Wed, 5 Jan 2000 doug@springer.net wrote:
> I have tentatively searched the linux kernel archives for this subject,
> but haven't found anything. I have heard that there is talk about
> moving this to 64 bits. Has anyone considered this (stupid
> question) and who else is interested in this subject. It seems to be
> a kernel and a glibc issue. Since I am not currently subscribed to
> the list, please cc doug@springer.net for any replies. When time
> allows, I intend to experiment with the 64 bit thing and see what
> breaks.
> -Doug Springer
>
If everything that references time_t size variables (in all applications
and the OS) are changed, and the applications recompiled, of course
nothing will break. However, the problem remains with applications that
think that struct timeval { long tv_sec, long tv_usec } is how it works.
These applications will have to be fixed. Since ix86 machines are not
64-bits, summation of a 64-bit (long long) is a bit of a problem. I have
heard that the current 'C' compilers doesn't do a very good job.
Even incrementing a 64-bit timer tick is a problem because an increment,
past zero doesn't set the carry flag. You need to do this:
addl $1, low_word
adcl $0, high_word
I think that before 38 years is up, none of us will be using 32-bit
machines so, even if I was 10 years old, I wouldn't bother 'fixing'
32-bit machines. Even Intel's new stuff is 64 bits.
Adding stuff to do 'long-long' operations on a 'long' machine will just
add wasted CPU cycles. I think you should leave it alone.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.35 on an i686 machine (400.59 BogoMips).
-
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/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:04 EST