Tugger the SLUGger!SLUG Mailing List Archives

Re: [SLUG] Your top-ten linux desktop apps

On Thu, Sep 29, 2005 at 10:40:47PM +1000, O Plameras wrote:
> The only change from 32-bit to 64-bit machine as far as
> data type sizes are concerned is 'long'. Changed from 4 to 8 bytes.
> This resolves the argument comprehensively.
> This means that there is going to be minimal improvements from
> a 32-bit to 64-bit PCs. 
> I had wanted to buy a 64-bit CPU, but with this I will defer.
> I need to check that documentation re AMD64.

When thinking about why things are as they are, it's always good to
consider the alternative outcome.  Imagine if the size of int did
increase to 64 bits.  Firstly a lot of code would break.  That's a
bug, and would eventually be fixed after some initial pain.

Suddenly every int variable now takes up twice as much space, every
array of ints is twice as big.  This means binary sizes increase and,
more importantly, you waste a lot of your cache.

How often does a loop counter overflow a 32 bit variable?  To be sane
people would have to reduce the size of variables they know won't
overflow.  So maybe you could make a short a 32 bit variable on your
64 bit machine.  But now when people try to move their code between
machines might find their counter becomes 16 bits, which is much more
realistically overflowed.  Now programmers have to be concerned about
sizeof(int) and sizeof(short) to maintain portability.  It would be a

64 bits is mostly about addressing; the times we need to cater for 64
bit variables that aren't addresses are limited.  I'd still consider
an AMD64; there are a number of architectural enhancements over x86.
Of course if you want a real 64 bit architecture, pick up an Itanium
from somewhere :)


Attachment: signature.asc
Description: Digital signature