by Andrew Binstock

To get you started, here's a quick overview of the basic issues developers will deal with in porting 32-bit code over to the world of the 64-bit Intel® Itanium® architecture, along with useful links to the full technical detail.

Due to the strategic importance of the 64-bit Intel® Itanium architecture to Intel's growth, the company has put in place numerous resources to assist developers in porting software. As discussed elsewhere on this site, the Itanium architecture is completely different from processors in the familiar x86 family; in fact, the architecture-named EPIC-is wholly different from all processors currently shipping. So, inducing developers to port applications to Itanium and use it to best effect is a crucial step in a successful launch.

Porting Application Source Code

The single biggest issue software developers should face in porting source code to the Itanium platform is the changes in pointer size and fundamental integer types. As such, these differences should appear most prominently in C and C++ programs. Code written in Fortran*, COBOL*, Visual Basic*, and most other languages (except assembly language, which must be completely rewritten), will need no modification. A simple recompilation should be all that is needed. Java* code should not even need recompilation-Java classes should execute the same on a 64-bit JVM as on any 32-bit virtual machine.

C (from here on, C++ is included in all discussions of C) code, however, by allowing casting across types and direct access to machine-specific integral types will need some attention.

The first aspect is the size of pointers. All operating systems on Itanium architecture will have 64-bit pointers. This means that

sizeof (ptrdiff_t) 

will equal 8 and no longer 4. As a result, structures that contain pointers will have different sizes as well. As such, if data laid out for these structures is stored on disk, reading it in or writing it out will cause errors. Likewise, unions with pointer fields will now have different sizes and can cause unpredictable results.

The greatest effect, though, will be felt wherever pointers are cast to integral types. This practice, which has been condemned for years as inimical to portability, will come back to haunt programmers who did not abandon it. The problems caused by it are traceable to the different widths used by pointers, integers, and longs on the various platforms. Let's examine these.

Microsoft* Windows* - Microsoft's Windows 64 (or Win64) migrates from the ILP32 model in which integer, long, and pointer (the ILP) were all 32 bits to the P64 model where pointers are 64 bits and integers and longs remain at 32 bits. This perforce means that changes will occur in the Windows API. For example, the function GetClassLong() returned a 32-bit quantity that could be either an integer or a pointer. Under the Wi n64 API, this has been changed to GetClassLongPtr(), which is properly behaved. UINT64 and INT64 represent the Microsoft names for the new integral types.

Information on porting to Win64 is available in many places on Microsoft's Website. A quick search will generate pointers to all different aspects of migrating to 64 bits. A fine treatment of the topic appears in a whitepaper entitled "Preparing Code for the Intel® IA-64 Architecture (Code Clean)."

Linux* - 64-bit Linux uses the LP64 model, where longs and pointers are 64 bits wide and integers remain fixed at 32 bits. This will involve changes similar to those described in the previous section.

The resources for Linux on Itanium processors are unfortunately rather scattered. Originally, the Trillian project was in charge of the Itanium architecture port. This became the IA-64 Linux Project with its home at http://www.ia64-linux.org/*. Many links there are out-of-date as are the links at almost all vendors contributing to the project. Despite this, there are useful resources available for developers. The most comprehensive presentation of code changes and system modifications due to Itanium is at http://www.ia64-linux.org/doc/IA64linuxkernel.PDF*. This presentation should cover just about all topic areas germane to developers.

Developers wanting the source code for the 64-bit Linux port can download it from www.kernel.org/pub/linux/kernel/ports/ia64/*.

HP-UX* - Hewlett-Packard is the co-creator of the Itanium architecture and its implementation. Direct compatibility with PA-RISC processor applications has been built into the Itanium processor family.

Porting Device Drivers

Device drivers are a unique class of software and far more sensitive to the internal changes made to the operating systems to run on IA-64. The specific nature of the changes range from those discussed, including especially changes to the OS APIs, to changes in data structures for internal systems tables and data blocks. Further information is available from the major vendors. For example, http://www.microsoft.com/whdc/system/platform/64bit/default.mspx* explains how to obtain the device driver kit (DDK) and DDK data from Microsoft.

Binary Portability

To assure that the new architecture will have an immediate software base, Intel made sure that existing binaries will run unmodified on the Itanium chip. Intel x86 binaries are translated by the Itanium processor and executed natively with all necessary register mappings performed correctly, such that you can take 32-bits Windows binaries and run them on 64-bit Windows without recompilation.

Interestingly, binaries for Hewlett-Packard's PA-RISC architecture can also be run without modification on the Itanium system. HP was a co-designer of the Itanium proces sor and assured thereby the ability to run PA-RISC binaries. To run these binaries, sites must use Aries* software that HP will bundle with all its systems. Aries performs two primary functions: it performs dynamic translation of PA-RISC binaries into native Itanium processor instructions for immediate execution, and it performs interpretation of other, lesser-used PA-RISC commands. Between these two functions, Aries can run all 32- 64-bit PA-RISC binaries on Itanium processors.

Finally, for a broad collection of links to useful training documents for developers, including discussions of porting in general as well as OS-specific porting issues, see the Intel® Developer Zone web site.

It appears that most vendors as well as the Linux community are dedicated to making it easy to port application code to Itanium. Watch out for the effects of larger pointers and the differences between the widths of ints and longs in C, and you will have covered most of the difficulties. Fortunately, the more recondite problems are documented well by the respective vendors.