PORTING Applications from 32 bit to 64 bit Architecture
Pallav singh
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
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
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
Paavo Helde
> 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
Maybe. In mainstream 64-bit Windows and Linux the pointers are indeed 64
bit and int is 32 bit. But size of long is different for those two, for
example.
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.
Paavo
SaticCaster
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
> Pallav singh <singh....@gmail.com> kirjutas:
>
>> Hi
>>
>> are these only the changes we need to do while porting application
>> from 32 bit architecture to 64 bit architecture ??
> 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=.