From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <427F65A6.2010803@9fs.org>
Date: Mon,  9 May 2005 14:29:10 +0100
From: Nigel Roles <nigel@9fs.org>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] Sleep-complexity
References: <8dc25d6e6eb4100818b09a511477f06e@terzarima.net>
In-Reply-To: <8dc25d6e6eb4100818b09a511477f06e@terzarima.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 4740c462-ead0-11e9-9d60-3106f5b1d025


>the assumption usually made in practice is a little more subtle:
>int <= long[=32] < long long [=64].  most older programs tended
>to use int for things such as for loop values, that probably needed to be
>at least 16 bits, but might not need to be as much as 32.
>by contrast, a `long' quite often needed to be 32 bits, and often
>that was `no more, no less'.
>
>  
>
I'll probably regret this, but the gcc x86_64 approach hasn't worked out 
too badly.
When we did our 64 bit port recently, it was only cases of trying to 
stash a pointer
in an int which bit us. When I say us, I mean the authors of certain
Linux packages. At one time I thought there was a maxim of "int is the 
efficient
machine size, long is big enough to hold a pointer", so gcc x86_64 can 
claim to
meet that reasoning.

Nigel