PORTING Applications from 32 bit to 64 bit Architecture

[Pallav singh]

Hi

are these only the changes we need to do while porting application
from 32 bit architecture to 64 bit architecture ??

In 64 bit architecture, Address is 64 bit but integer is still 32 bit

Architecture Dependencies (64 bit vs 32 bit)
• Data Types and Sizes
• Pointers
Type casts, setting to 0, comparison, pointer arithmetic
• Data Alignment and Padding
Member Alignment, Structure Alignment
• Bit Shifts
Result Type
• Constants
Constant values may have differ(related to size issue)
• Library Calls and Operators
printf, scanf, malloc, calloc, sizeof, memcpy etc

Endianism (Little Endian vs Big Endian)
• Byte Ordering
• Initializing Multiword Entities
• Unused Bytes
Bit masks etc
• Hex Constants Used as Byte Arrays
• Data Transfer Between LE and BE Systems

Other OS Dependencies
• Interprocess Communication (Blocking vs Non Blocking calls)
• Timers
• Signals
Reliable and unreliable
• Communication Stacks, subsystems
• Language Extensions
Ex: Librairies like X11, ACE etc
• Memory mapped files, asynchronous I/O, performance
constraints etc

Tools and Utilities
• Build Environment
Compiler flags, #pragma definitions, default options etc
• Object Formats (Most systems use ELF)

Thanks
Pallav Singh

 

[Victor Bazarov]

Hi

What's wrong? You post an almost identical article three minutes (!)
apart. Are you impatient to get a reply? Well, this isn't a chat room.
Are you experiencing problems? Contact your ISP. Please refrain from
polluting the cyberspace.

are these only the changes we need to do while porting application
from 32 bit architecture to 64 bit architecture ??

In 64 bit architecture, Address is 64 bit but integer is still 32 bit

No, not necessarily. Besides, there are different integers in C++, some
are 32 bit, some are 16 bit, and some even 8 bit (signed char, for
example). It is all platform-specific.

[.. long list of "only" changes ..]

I strongly recommend that you ask your platform-specific question in the
newsgroup dedicated to your platform.

Generally speaking, your program needs to be written in such a way that
it does not depend on the *size* of the data it operates, or the
endianness of the storage. Then you have no problems shifting from one
environment to the next.

V

 

[SG]

Generally speaking, your program needs to be written in such a way that
it does not depend on the *size* of the data it operates, or the
endianness of the storage.  Then you have no problems shifting from one
environment to the next.

Or even shorter:

non-portable <=> dependence on implementation-defined behaviour

I think that catches it. Of course, the trick is then to know what
part of C++ is implementation-defined.


Cheers!
SG

 

[Jorgen Grahn]

Hi

are these only the changes we need to do while porting application
from 32 bit architecture to 64 bit architecture ??

They are not changes, but areas where it might matter.
I cannot tell if it is complete.

In 64 bit architecture, Address is 64 bit but integer is still 32 bit

Likely, but not necessarily true. "64-bit" is not very well defined.

[snip list of areas]

The only problem I've encountered when porting to Linux on AMD64 was
braindead code which relied on struct memory layout.

Another change is increased memory usage for pointer-intensive data
structures. (Can't remember if you listed it.)

/Jorgen

 

[SaticCaster]

20 issues of porting C++ code on the 64-bit platform
http://www.viva64.com/art-1-2-599168895.html

The forgotten problems of 64-bit programs development
http://www.viva64.com/art-1-2-16511733.html

64 bits, Wp64, Visual Studio 2008, Viva64 and all the rest...
http://www.viva64.com/art-1-2-621693540.html

Optimization of 64-bit programs
http://www.viva64.com/art-1-2-1756520624.html

AMD64 (EM64T) architecture
http://www.viva64.com/art-1-2-1496710594.html

 

[Jorgen Grahn]

....

For porting my code to 64-bit the main problem was that the result of
std::string::find() and friends was often stored in an unsigned int, which
made it impossible to compare with std::string::npos. Fortunately enough,
g++ spits out good warnings about this.

Come to think of it, that's probably the best advice: turn on every
compiler warning you can find[1], and review all places where the code
discards type information (casts and so on).

Doing this with just "g++ -c foo.cc" is doing it blindfolded.

/Jorgen

[1] In the g++ case, at least -W, -Wall, -pedantic and -std=.