lkml.org 
[lkml]   [1999]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Migrating to larger numbers
    Keep in mind that 40 years ago we were just entering the "Second
    Generation Computers (1956-1963)"
    (http://www.digitalcentury.com/encyclo/update/comp_hd.html) which started
    out with the transistor. 40 years is a long time.

    The problem is using a 64-bit time_t on a 32-bit system, especially on an
    embedded one where performance per $ counts... long longs are SLOW, and
    for such a commonly used value it would be a significant performance hit.

    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.

    Oh. And keep in mind that linux won't even run on a 16-bit machine
    (although there was a port to the 286 at one point?)... :-)
    -Rob

    On Tue, 1 Jun 1999, Ard van Breemen wrote:

    > Date: Tue, 1 Jun 1999 07:39:40 +0200 (CEST)
    > From: Ard van Breemen <ard@cstmel.nl.eu.org>
    > To: linux-kernel@vger.rutgers.edu
    > Subject: Re: Migrating to larger numbers
    >
    > On Mon, 31 May 1999 hagopiar@vuser.vu.union.edu wrote:
    > > But there might be a way to compromise: Would it be possible to make
    > > uid_t/gid_t implementation specific? As I read it, __kernel_time_t is an
    > > unsigned long. If my memory serves (which is growing less and less likely
    > > these days), this means that it is a 64-bit value on 64-bit architectures
    > > and a 32-bit value on 32-bit architectures. This is the route that Sun
    > > took with their 64-bit architectures with time_t, based on the (IMO
    > > perfectly valid) assumption that in 38 years 32-bit binaries will be done
    > > with.
    > This is not a valid assumption, and there is 1 good example for that:
    > Y2K...
    > The idea that 32 bit will be obsolete is probably non-true. We are still
    > using 4 and 8 bit microcontrollers. By then a lot of 32 bit
    > microcontrollers will be common in regular appliances. Those appliances
    > will by then be more complex, and therefore need a base that already has
    > no time problems.
    > I can see the logica with the amount of users on a 32 bit system, but not
    > with the time. 38 years is not that long, and I know that there still will
    > be a lot of 32 bit controllers out there (and even 8 and 4 bit...)
    >
    >
    > --
    > intel1: 7:29am up 26 days, 7:17, 10 users, load average: 0.00, 0.00, 0.00
    >
    >
    > -
    > 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/
    >


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.022 / U:61.416 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site