Advanced Topics
This chapter presents a collection of miscellaneous programming topics for systems programmers who want to understand more about the 64-bit Solaris operating environment.
What's New for Applications
Most of the new features of the 64-bit environment are extensions of generic 32-bit interfaces, though several new features are unique to 64-bit environments.
64-bit: ABI Features
64-bit applications are described using Executable and Linking Format (ELF64), which allows large applications and large address spaces to be described completely.
ABI Features: SPARC V9
The SPARC Compliance Definition, Version 2.4, contains details of the SPARC V9 ABI. It describes the 32-bit SPARC V8 ABI and the 64-bit SPARC V9 ABI. You can obtain this document from SPARC International at www.sparc.com.
Following is a list of the SPARC V9 ABI features.
The SPARC V9 ABI allows all 64-bit SPARC instructions and 64-bit wide registers to be used to their full effect. Many of the new relevant instructions are extensions of the existing V8 instruction set. See The SPARC Architecture Manual, Version 9.
The basic calling convention is the same. The first six arguments of the caller are placed in the out registers %o0-%o5. The SPARC V9 ABI still uses a register window on a larger register file to make calling a function a "cheap" operation. Results are returned in %o0. Because all registers are now treated as 64-bit quantities, 64-bit values can now be passed in a single register, rather than a register pair.
The layout of the stack is different. Apart from the increase in the basic cell size from 32-bit to 64-bit, various "hidden" parameter words have been removed. The return address is still %o7 + 8.
%o6 is still referred to as the stack pointer register %sp, and %i6 is the frame pointer register %fp. However, the %sp and %fp registers are offset by a constant, known as the stack bias, from the actual memory location of the stack. The size of the stack bias is 2047 bits.
Instruction sizes are still 32 bits. Address constant generation therefore takes more instructions. The call instruction can no longer be used to branch anywhere in the address space, since it can only reach within plus or minus 2 gigabytes of %pc.
Integer multiply and divide functions are now implemented completely in hardware.
Structure passing and return are accomplished differently. Small data structures and some floating point arguments are now passed directly in registers.
User traps allow certain traps from non-privileged code to be handled by a user trap handler (instead of delivering a signal).
All data types are now aligned to their size.
Many basic derived types are larger. Thus many system call interface data structures are now of different sizes.
Two different sets of libraries exist on the system: those for 32-bit SPARC applications and those for 64-bit SPARC applications.
Stack Bias
An important feature of the SPARC V9 ABI for developers is the stack bias. For 64-bit SPARC programs, a stack bias of 2047 bytes must be added to both the frame pointer and the stack pointer to get to the actual data of the stack frame. See the following figure.
For more information on stack bias, please see the SPARC V9 ABI.
Address Space Layout: SPARC V9
For 64-bit applications, the layout of the address space is closely related to that of 32-bit applications, though the starting address and addressing limits are radically different. Like SPARC V8, the SPARC V9 stack grows down from the top of the address space, while the heap extends the data segment from the bottom.
The diagram below shows the default address space provided to a 64-bit application. The regions of the address space marked as reserved might not be mapped by applications. These restrictions might be relaxed on future systems.
The actual addresses in the figure above describe a particular implementation on a particular machine, and are given for illustrative purposes only.
Placement of Text and Data
By default, 64-bit programs are linked with a starting address of 0x100000000. The whole program is above 4 gigabytes, including its text, data, heap, stack, and shared libraries. This helps ensure that 64-bit programs are correct by making it so the program will fault in the lower 4 gigabytes of its address space, if it truncates any of its pointers.
While 64-bit programs are linked above 4 gigabytes, you can still link them below 4 gigabytes by using a linker mapfile and the -M option to the compiler or linker. A linker mapfile for linking a 64-bit SPARC program below 4 gigabytes is provided in /usr/lib/ld/sparcv9/map.below4G.
See the ld(1) linker man page for more information.
Code Models
Different code models are available from the compiler for different purposes to improve performance and reduce code size in 64-bit SPARC programs. The code model is determined by the following factors:
Positionability (absolute versus position-independent code)
Code size ( < 2 gigabytes)
Location (low, middle, anywhere in address space)
External object reference model (small or large)
The following table describes the different code models available for 64-bit SPARC programs.
Table 6-1 Code Model Descriptions
Code Model | Positionability | Code Size | Location | External Object Reference Model |
|---|---|---|---|---|
abs32 | Absolute | < 2 gigabytes | Low (low 32 bits of address space) | None |
abs44 | Absolute | < 2 gigabytes | Middle (low 44 bits of address space) | None |
abs64 | Absolute | < 2 gigabytes | Anywhere | None |
pic | PIC | < 2 gigabytes | Anywhere | Small (<= 1024 external objects) |
PIC | PIC | < 2 gigabytes | Anywhere | Large (<= 2**29 external objects) |
Shorter instruction sequences can be achieved in some instances with the smaller code models. The number of instructions needed to do static data references in absolute code is the fewest for the abs32 code model and the most for the abs64 code model, while abs44 is in the middle. Likewise, the pic code model uses fewer instructions for static data references than the PIC code model. Consequently, the smaller code models can reduce the code size and perhaps improve the performance of programs that do not need the fuller functionality of the larger code models.
To specify which code model to use, the -xcode=<model> compiler option should be used. Currently, for 64-bit objects, the compiler uses the abs64 model by default. You can optimize your code by using the abs44 code model; you will use fewer instructions and still cover the 44-bit address space that the current UltraSPARC platforms support.
See the SPARC V9 ABI and compiler documentation for more information on code models.
Note - A program compiled with the abs32 code model must be linked below 4 gigabytes using the -M /usr/lib/ld/sparcv9/map.below4G option.