x86_64

[gaf at blu.org (Jerry Feldman)]

On Tuesday 07 March 2006 6:43 am, jbk wrote:
> James Kramer wrote:
> > Some questions I have and would appreciate some insight.  It seems to
> > me that Xen type systems may become more common in the future.  If so,
> > would 64 bit be a better option?  How much difference is there in
> > converting software to 64 bit.  I realize that memory allocation would
> > be different but is there much more work then recompiling the code?
> > These are all questions--I don't know the answers.  I have converted
> > some Fortran code from 64 bit mainframe to 16 bit PC and I really don't
> > remember worrying about the number of bits.  How much more conversion
> > is necessary.
One of the benefits of 64-bit computing is the large linear address space. A 
32-bit application is limited to effectively 2GB where 64-bit computing is 
limited to 4 exabytes. Where 64-bit computing wins here is in the database 
arena, but other memory-intensive applications also benefit. In the case of 
FORTRAN, there should be very few issue in porting an application. Where 
the effort is is in languages like C and C++. Linux (and all Unix systems) 
uses the LP64 model where both longs and pointers are 64-bits on a 64-bit 
system. There can be some interesting pathalogical issues such as when 
signs extend or don't:
long n;
int i = -2;
unsigned k = 1;
n = i + k;
Result:
32-bit n == -1
64-bit n == 4294967295 (eg. MAX_UINT).
In the above case, the sign does not extend because the expression (i + k) 
is an unsigned 32-bit integer according to the C standard. 

Additionally, the endianness can make a difference:
long n;
int *pn;

pn = &n; /* note this may cause a warning */
The expression (*pn) returns a 32-bit int containing the first 32-bits of n 
on a 64-bit system.
On a little endian system, this would be the least significant 4 bytes of n. 
So, if the value of n is <= 2147483647, then *pn would contain the correct 
value. On a big endian machine, this would be the most significant bits, so 
if the value of n <= 2147483647, *pn would be zero.

WRT: the Dec/Compaq/HP Alpha. Dec/Compaq essentially owned the HPTC market 
with those chips. In that market they were very fast, but one area that 
hurt the Alpha was that the earlier chips (EV4 and EV5) did not have byte 
and word (2 bytes) instructions, so that all memory access had to be either 
longword (4 bytes) or quadword(8 bytes). These instructions were added in 
the EV56 chip. Effectively, the computer makers cannot produce proprietary 
chips in enough volume to justify the development costs, hence the sale of 
the Alpha technology (as well as the compiler technology) to a chip maker 
(eg. Intel). 
-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9