As discussed in Getting Past the 4 Gigabyte Barrier, most 32-bit applications run unchanged in the Solaris 64-bit operating environment. Some applications might only need to be recompiled as 64-bit applications, others need to be converted. This chapter is directed at developers who have determined that their application needs to be recompiled or converted to 64-bit, based on the items discussed in Getting Past the 4 Gigabyte Barrier.
The 32-bit application programming interfaces (APIs) supported in the 64-bit operating environment are the same as the APIs supported in the 32-bit operating environment. Thus, no changes are required for 32-bit applications between the 32-bit environment and 64-bit environment. However, recompiling as a 64-bit application can require cleanup. See the rules that are defined in Chapter 4, Converting Applications for guidelines on how to clean up code for 64-bit applications.
The default 64-bit APIs are basically the UNIX 98 family of APIs. Their specification is written in terms of derived types. The 64-bit versions are obtained by expanding some of the derived types to 64-bit quantities. Correctly written applications that use these APIs are portable in source form between the 32-bit environment and 64-bit environment. The UNIX 2001 API family is also available in Solaris 10, see standards(5).
The SPARC V8 ABI is the existing processor-specific Application Binary Interface (ABI) on which the 32-bit SPARC version of the Solaris implementation is based. The SPARC V9 ABI extends the SPARC V8 ABI to support 64-bit operations and defines new capabilities for this extended architecture. See SPARC V9 ABI Features for additional information.
The i386 ABI is the processor-specific ABI on which the 32-bit version of Solaris (Intel Platform Edition) is based.
For the Solaris 10 release, the amd64 ABI is the processor-specific ABI on which the 64-bit version of Solaris on x86 systems is based. The amd64 ABI supports 64-bit operations and defines new capabilities for the new architecture. Programs using the 64-bit ABI might perform better than their 32-bit counterparts. Processors that support the amd64 ABI also support the i386 ABI. See AMD64 ABI Features for additional information.
The following sections discuss the different levels of compatibility between 32-bit applications and 64-bit applications.
Existing 32-bit applications can run on either 32-bit or 64-bit operating environments. The only exceptions are those applications that use libkvm, /dev/mem, /dev/kmem, or /proc. See Getting Past the 4 Gigabyte Barrier for more information.
Source level compatibility has been maintained for 32-bit applications. For 64-bit applications, the principal changes that have been made are with respect to the derived types used in the application programming interface. Applications that use the derived types and interfaces correctly are source compatible for 32-bit, and make the transition to 64-bit more easily.
Because 32-bit device drivers cannot be used with the 64-bit operating system, these drivers must be recompiled as 64-bit objects. Moreover, the 64-bit drivers need to support both 32-bit applications and 64-bit applications. All drivers supplied with the 64-bit operating environment support both 32-bit applications and 64-bit applications. However, the fundamental driver model and the interfaces supported by the DDI do not change. The principal work is to clean up the code to be correct in an LP64 environment. See the Writing Device Drivers manual for more information.
The Solaris operating environment supports two first-class ABIs simultaneously. In other words, two separate, fully functional system call paths connect into the 64–bit kernel. Two sets of libraries support applications.
The 64-bit operating system can run on only 64-bit CPU hardware, while the 32-bit version can run on either 32-bit CPU hardware or 64-bit CPU hardware. Because the Solaris 32-bit and 64-bit operating environments look very similar, it might not be immediately apparent which version is running on a particular hardware platform.
The following is an example of the isainfo command executed on an UltraSPARC system running the 64-bit operating system:
% isainfo -v 64-bit sparcv9 applications 32-bit sparc applications
When the same command is run on an x86 system runnig the 32–bit Solaris operating system:
% isainfo -v 32-bit i386 applications
When the same command is run on an x86 system running the 64–bit Solaris operating system:
% isainfo -v 64-bit amd64 applications 32-bit i386 applications
Not all x86 systems are capable of running the 64-bit kernel. In this case, if the system is running the in Solaris operating environment, the kernel is running in 32-bit mode
One useful option of the isainfo(1) command is the -n option, which prints the native instruction set of the running platform:
% isainfo -n sparcv9
The -b option prints the number of bits in the address space of the corresponding native applications environment:
% echo "Welcome to "`isainfo -b`"-bit Solaris" Welcome to 64-bit Solaris
Applications that must run on earlier versions of the Solaris operating environment can ascertain whether 64–bit capabilities are available. Check the output of uname(1) or check for the existence of /usr/bin/isainfo.
A related command, isalist(1), is more suited for use in shell scripts. isalist can be used to print the complete list of supported instruction sets on the platform. However, as the number of instruction set extensions increases, the limitations of a list of all subsets has become apparent. Users are advised to not rely upon this interface in the future.
Users who create libraries that depend upon instruction set extensions should use the hardware capability facility of the dynamic linker. Use the isainfo command to ascertain the instruction set extensions on the current platform.
% isainfo -x amd64: sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc fpu i386: sse2 sse fxsr amd_3dnowx amd_3dnow amd_mmx mmx cmov amd_sysc cx8 tsc fpu