Open System Services Programmer's Guide

C/C++ Language Features Supporting 64-Bit Addressing
Beginning with the H06.24 and J06.13 RVUs, the C/C++ compilers hosted on Guardian, OSS,
and Windows support a command-line directive to specify the data model in the resulting
compilation. The syntax is slightly different between the Guardian compilers and the other compilers.
For detailed information about the NonStop C/C++ compilers in the OSS, Windows, and Guardian
environments, see the latest C/C++ Programmer's Guide for NonStop Systems in the NTL.
32-bit and 64-bit versions of DLLs are provided. (See “32-Bit and 64-Bit Public DLLs” (page 293) for
details.) The specified data model (ILP32 or LP64) for the C/C++ compilers and the eld linker
causes the correct run-time DLLs to be selected if the build file uses the shorthand DLL name. For
example, if “-l CRE” is in the build file, rather than “-l ZCREDLL”, the linker selects the
appropriate 32-bit or 64-bit DLL (ZCREDLL or YCREDLL, respectively), depending on whether the
ILP32 or LP64 data model was specified for the compilation.
32-Bit and 64-Bit Applications Constraints
Consider these constraints for 32-bit and 64-bit applications:
• When sharing memory segments between 32-bit and 64-bit processes, interpretation of bits
inside the memory segment and their semantics is the application’s responsibility.
• Programs must be compiled using either the ILP32 or the LP64 data model and you cannot
mix the two data models into one program.
• Migrating a 32-bit application to a 64-bit application might require source code changes.
• Migrating a 32-bit application to a 64-bit application requires minor build-script changes.
• The virtual memory available for heap data is expanded. The virtual memory available for
program text, DLL text, and global data is not expanded.
IMPORTANT: A 64-bit process’s stack is currently 32-bit addressable. However, this might not
be true in the future; therefore, HP does not recommend the use of 32-bit pointers referring to local
variables in a 64-bit program.
Fallback Considerations
If no new 64-bit features were used after migrating from a preceding release to the H06.24 or
J06.13 RVU, there will be no fallback impact and no application changes are required.
If 64-bit features were used in either the H06.24 or J06.13 RVU, and then a fallback to a preceding
release occurs, then one of the following is required:
• Applications that were compiled in the LP64 data model must be rebuilt in the ILP32 data
model.
• The previous 32-bit binaries must be used.
64-Bit Support for OSS and Guardian APIs
The 64-bit programming model supports coexistence of 32-bit and 64-bit applications on TNS/E
systems. These applications in different data models can communicate using IPC mechanisms,
including shared memory segments. TNS/E 32-bit non-privileged object files will continue to run
without recompiling or relinking.
Changed OSS Functions
Beginning with the H06.24 and J06.13 RVUs, all OSS functions in the Open System Services
System Calls Reference Manual and the Open System Services Library Calls Reference Manual
have pointers and long data types widened to 64 bits and are callable from 64-bit OSS programs.
64-bit OSS applications can continue to use the same function name when calling these functions.
292 64-Bit Support in OSS and Guardian