User-Level Native Thread Primitives (GThread) Library White Paper (G06.27+, H06.03+, J06.03+)

User-Level Native Thread Primitives (GThread Library) 02/15/2012
540065-004 Page 6 of 44
passed into GTHREAD_INITIATE, so that the Gthread library will initiate the user thread using a
protected stack.
1.7. Changes to Support 64-bit Addresses
Starting from the H06.24 and J06.13 Release Version Updates, the GThread library supports 64-bit OSS
processes. The 64-bit OSS process infrastructure is built by using 64-bit addresses and the LP64 data
model, wherein the long int and the default pointer types are 64 bits wide. 64-bit OSS processes can
access and use 64-bit memory. The main heap of a 64-bit OSS process is in the 64-bit addressable
memory. 64-bit processes can also allocate 64-bit addressable flat segments, but the stacks and process
global data remain in the 32-bit addressable memory.
Wherever relevant, Gthread APIs are widened to accept 64-bit addresses. The APIs are widened in such a
way that the same interface can support both the 32-bit and 64-bit callers. The principal change is that
GThread_CB becomes a 64-bit pointer, so the GThread control blocks can be in either 32-bit or 64-bit
address space. Other pointer parameters are automatically widened when compiled in the LP64 data
model. However, due to system constraints, the static stacks must be allocated in 32-bit address space.
Note: The GThread primitives do not support 64-bit processes in pTAL or TAL.
1.7.1. __LP64 Macro
A new predefined feature test macro is introduced to ease the transition to 64-bit addressing and to
separate the 32-bit and 64-bit code. The __LP64 macro is set internally by the NonStop C/C++ compilers
when invoked using the LP64 data model.
The __LP64 macro helps to differentiate structures and declarations in the header files. The difference
between the two data models (ILP32 and LP64) is coded as follows:
#ifdef __LP64
64-bit code here
#else /* ! __LP64 */
32-bit code here
#endif /* ! __LP64 */