Porting Code from 32 bit to 64 bit Architecture
patrick
I am looking for a concrete example and explanation on where I will run
into or could run into problems when porting an application from a 32 bit
architecture to 64 bit. What exactly would I have to do in my code to cause
an incompatibility ?? I am sorry if this question is a bit too vague, but I
am having trouble seeing where the errors can occur. A concrete example
would be very much appreciated.
Thank you
Patrick Brown
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Jens Kilian
> I am looking for a concrete example and explanation on where I will run
> into or could run into problems when porting an application from a 32 bit
> architecture to 64 bit. What exactly would I have to do in my code to cause
> an incompatibility ?? I am sorry if this question is a bit too vague, but I
> am having trouble seeing where the errors can occur. A concrete example
> would be very much appreciated.
Different pointer alignment and/or structure padding rules may cause trouble.
The built-in types (esp. pointers) may differ in size (a typical 64-bit
implementation, HP-UX 11.x, uses an LP64 model, which means that 'long' and
pointers are 64bit, while 'int' remains a 32-bit type).
Device drivers (if you have any custom ones) may need to be rewritten to cope
with accesses from both 32-bit and 64-bit applications.
Without knowing which architecture you refer to, it's hard to give more
concrete advice.
Bye,
Jens.
--
mailto:j...@acm.org phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
Steve Clamage
> into or could run into problems when porting an application from a 32 bit
> architecture to 64 bit. What exactly would I have to do in my code to cause
> an incompatibility ?? I am sorry if this question is a bit too vague, but I
> am having trouble seeing where the errors can occur. A concrete example
> would be very much appreciated.
>
> Thank you
> Patrick Brown
>
First, lets notice that different 64-bit systems make different
choices for the sizes of basic types.
Even assuming a flat address space and uniform 64-bit pointers,
choosing the size of int and long is difficult. Some systems
prefer to leave int and long at 32 bits, with a long long type
as the only 64-bit integer. Other systems choose to keep long
and pointer as the same size, with integers remaining 32 bits.
There are probably systems with 64-bit ints.
The most common portability problems come from hidden assumptions
in the code about the relative sizes of int, long, and pointers.
An amazing amount of code makes assumptions that int and long have
the same representation, or that int and pointers are the same size.
Either or both of these assumptions can be wrong when moving to a
64-bit system.
Some code goes farther, quietly assuming that ints, longs, or
pointers are exactly 32 bits or 4 bytes in size.
The worst part is that code may compile and link without error on
a 64-bit system, but fail in strange ways, or fail only for some
sets of input data.
A more subtle problem concerns type promotion rules involving type
long long, which was not a standard type before the new 1999 C
standard. Depending on the type promotion rules for the non-standard
type (which vary among systems), you might get a different result
when a value is promoted to a system with 64-bit longs than when
promoted to a system when only long long has 64 bits. Few programs
are likely to be affected, although you can construct examples that
behave differently.
If you follow good programming practices and use the standard language
facilities to discover the size and range of basic types, you should
have few problems porting your code. But no matter how good you are,
you may be using code from someone else who was less careful.
--
Steve Clamage, stephen...@sun.com
Steve Clamage
The most commonly-reported bug comes from calling malloc without
including the header that declares it. In C, an undeclared
function is assumed to return an int. Most C compilers don't complain
very much about assigning an int to a pointer, or programmers turn
off the warnings.
The common result is that the 64-bit pointer returned from malloc is
truncated to 32 bits before it is passed along. What happes after that
depends on the OS, among other things.
On Solaris, a truncated 64-bit address is not a valid address, and
the program traps on at the first attempt to dereference the pointer.
On other systems, you might not have a problem until the actual address
returned would not fit in an int, and you got a well-formed address
referring to the wrong location.