x86_64

[gaf at blu.org (Jerry Feldman)]

On Tuesday 07 March 2006 9:19 am, Ed Hill wrote:
> Some code (C, C++, Fortran, and other languages) written for i386 is
> "64-bit clean" and will work with just a recompile. ?And some code
> requires a bit of extra work to fix problems such as assumptions that
> ints and pointers are the same size.
In my experience, I have found that porting some code (mostly C, but also 
C++) can be more than trivial. Certainly, bad assumptions, such as 
sizeof(int) == sizeof(pointer) is certainly a bad assumption. But there are 
some very subtle errors that are very hard to track down. I mentioned a 
couple in my previous post, but another issue tends to be the use of masks 
and other constants. 
For instance, the hex constants:
0x7fffffff; - This is a signed int.
0xffffffff; - This is an unsigned int. 
Although both of these constants are the same size (32-bits) the C standard 
has some interesting rules that a lot of programmers do not know. When I 
wrote a white pater on 32-bit to 64-bit migration and also reviewed one of 
my colleague's (who I consider very competent) presentations, he had made a 
statement that hex constants were unsigned. I've also seen this in some 
books, but when one reads the standards (C89 and C99) that is not true. 
Another area that can cause problems is bit shifting:
The expression:
long n;
1 << n; -- This is an int (32-bit) expression.
1L << n; - This is a long expression.

In C++ I just ran into a case where there were constructors for, int, 
unsigned int, long, and a few more that don't concern us. 
But, in C and C++ lengths are defined as size_t (unsigned size). 
When the code is ported to 64-bits, the constructor could not be found since 
the constructor for unsigned long had not been defined.  
-- 
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