There are architectural differences between the Solaris 10 OS on SPARC-based systems and the Solaris 10 OS on x64/x86-based systems. The Solaris 10 OS is designed to be compatible with each of these architectures.
Some of the major differences between these architectures include the following:
* Byte ordering of the processor (endianness)
* 32-bit and 64-bit issues
* Direct memory access (DMA) compared to direct virtual memory access (DVMATM)
* Floating point operation
* Input/output (I/O) architecture
* Device drivers
* The boot process
* Remote installations (JumpStartTM software)
* Hot-plugging and dynamic reconfiguration
Endianness is the method of storing information in a computer’s memory. To achieve the goal of multiple-platform, multiple-instruction set architecture portability, the first dependency issue to address is the endianness of the processor.
When the most significant byte (MSB) of any multi-byte data field is stored at the lowest memory address, which is also the address of the larger field, then the system is said to be big-endian. When the least significant byte (LSB) of any multi-byte data field is stored at the lowest memory address, then the system is called little-endian.
For example, consider the integer 260 (hexadecimal equivalent is 0×0104). Suppose the value is stored at address 100 and 101.
* To view how a big-endian system stores the integer
Address
Value
0×100
0
0×101
0
0×102
01
0×103
04
* To view how a little-endian system stores the integer
Address
Value
0×100
04
0×101
01
0×102
0
0×103
0
Numeric data is stored in memory in a different format depending upon whether the target implementation platform is based on x64/x86 or UltraSPARC technology. The SPARC-based systems implement the MSB first and so are big-endian. The Solaris 10 OS x64/x86-based systems implement the LSB first and are called little-endian.
You can use the Solaris OS in both big-endian mode (Solaris 10 OS on SPARC-based systems) and in little-endian mode (Solaris 10 OS on x64/x86-based systems). Endianness is mandated by the hardware platform used. One of the strengths of the Solaris 10 OS is that it handles the endianness issue.
This prevents independent software vendors (ISVs) or developers from becoming concerned about how quickly their applications will be available on x64/x86-based systems platforms. Sun’s software architecture allows big-endian applications for the Solaris 10 OS on SPARC-based systems to run on the little-endian Solaris 10 OS x64/x86-based systems when they are recompiled. In general, no re-engineering is needed.
Issues relating to 32-bit and 64-bit technology apply to drivers as well. UltraSPARC III chips require a 64-bit kernel driver. The x86 processors are 32-bit, x64 processors are 64-bit and can be 32-bit compatible.
If existing drivers are developed using the Solaris software device driver interface (DDI) or driver-kernel interface (DKI) for the 64-bit kernel on the Solaris 10 OS on SPARC-based systems, you should not experience problems when porting to the Solaris 10 OS on x64/x86-based systems. You need to recompile the driver to run correctly in the 32-bit x86 processor.
The platform that the device operates on might provide one of the following two types of memory access:
* DMA - The Solaris 10 OS on x64/x86-based systems supports DMA
* DVMA - The Solaris 10 OS on SPARC-based systems supports DVMA
On platforms that support DMA, the system provides the device with a physical address to perform transfers. In this case, one logical transfer might actually consist of a number of physically discontiguous transfers. An example of this occurs when an application transfers a buffer that spans several contiguous virtual pages that map to physically discontiguous pages.
To deal with the discontiguous memory, devices for these platforms usually have some kind of scatter and gather DMA capability. Typically, the system that supports the Solaris 10 OS on x64/x86-based systems provides physical addresses for direct memory transfers.
The difference between these two memory access types requires major changes in porting a Solaris 10 OS on SPARC-based systems driver to the Solaris 10 OS on x64/x86-based systems.
In Solaris 10 OS on x64/x86-based systems, the floating-point registers are 80 bits wide, while in the Solaris 10 OS on SPARC-based systems, the floating point registers are 64 bits wide. Due to this, the computation results can differ because intermediate results of arithmetic computations can be in extended precision.
Note: For more information concerning floating point operation differences, refer to the Numerical Computation Guide at http://docs.sun.com/source/806-3568/.
The Solaris 10 OS on x64/x86-based systems I/O controllers uses special IN/OUT instructions to access the protocol control information (PCI) I/O space. The Solaris 10 OS on SPARC-based systems I/O controllersuses access to the PCI I/O space the same as it uses access to the memory space. Solaris on SPARC-based systems communicates with I/O devices through memory. A range of memory locations is logically replaced by device registers.
The Solaris 9 OS on x64/x86-based systems accesses I/O ports through the I/O address space using a set of I/O instructions and a special I/O protection mechanism. The processor’s general-purpose move and string instructions handle accessing I/O ports through memory-mapped I/O.
Segmentation and paging provide protection. You might map I/O ports so that they appear in the I/O address space, the physical-memory address space (memory-mapped I/O), or both.
The Solaris 10 OS on SPARC-based systems assumes that I/O registers are accessed using the following:
* Load/store alternate instructions
* Normal load/store instructions
* Coprocessor instructions
* Read ancillary state register (RDASR) instructions
* Write ancillary state register (WRASR) instructions
In the case of load/store alternate instructions, only the supervisor can access the I/O registers. In the case of all other types of instructions, the implementation determines whether people other than supervisors can access the I/O registers.
Device drivers are modules that plug into the Solaris kernel and provide access to I/O devices, including disks, tapes, compact disc read-only memory (CD-ROM/DVD-ROM) drives, serial ports, and networks.
The Solaris OS DDI/DKI interfaces standardize and document all interfaces between the device driver and the kernel. These interfaces also shield the driver from platform-specific dependencies by handling mismatches between processor and device endianness, and by enforcing any data-ordering dependencies the device might have.
In addition, the Solaris OS DDI/DKI interfaces provide source compatibility for drivers on any machine running the Solaris 10 OS, regardless of the processor architecture, such as SPARC or x64/x86. By using these interfaces, you can develop a single-code base driver that runs on both the SPARC and x64/x86 processor families
The standard basic input/output system (BIOS) in the x64/x86 booting architecture is often not capable of booting from all possible boot devices. On Solaris 10 OS x64/x86-based systems, the second-stage bootstrap serves another very important purpose. The second-stage bootstrap provides the services that are performed by open firmware on SPARC-based systems for the kernel and other clients.
On Solaris 10 OS on SPARC-based systems, the OpenBootTM programmable read-only memory (PROM), or OpenBoot PROM, provides the necessary support to allow booting from non-standard boot devices such as networks and CD-ROM/DVD-ROM drives. This capability is used during installation from a network or CD-ROM/DVD-ROM device, and by diskless (net-booting) Solaris OS clients.
The Solaris 10 OS on x64/x86-based systems uses the platform BIOS to support booting from disk drive, floppy diskette CD-ROM/DVD devices or network devices.
An x64/x86-based system that is to have the Solaris 10 OS installed on it can be jumpstarted from the Solaris 10 OS SPARC-based JumpStart server and conversely a SPARC-based system can be jumpstarted with Solaris 10 by an x64/x86-based JumpStart Server.
Hot-plugging is the ability to physically add, remove, or replace system hardware components while the system is running. Dynamic reconfiguration (DR) enables you to dynamically reconfigure, remove, or install core system components into your server while the Solaris 10 OS and your applications are running. DR also refers to the general ability to move system resources (both hardware and software) around in the system or to disable them in some way without physically removing them from the system.
You can hot-plug the following devices with the cfgadm command:
* Universal Serial Bus (USB) devices on the Solaris 10 OS on SPARC-based and x64/x86-based systems
* Small Computer Systems Interface (SCSI) devices on the Solaris 10 OS on SPARC-based and x64/x86-based systems
Note: Hot-plugging of PCI devices is not supported on the Solaris 10 OS on SPARC-based systems except on the Sun FireTM V880 server. However, hot-swapping (automatic device mapping updated in the OS) is supported by the Sun Fire systems and Compact Peripheral Component Interface (cPCI) boards on the NetraTM servers.
There are technical and performance differences concerning processors on x86 32-bit-based systems and x64 64-bit-based systems. The Solaris 10 OS on x64/x86-based systems is supported on many vendors’ systems.
Sun Microsystems has entered the x64/x86 marketplace with the following new x64/x86-based systems:
* Sun Fire V20z
* Sun Fire V40z Server
* Sun Fire V60x Server
* Sun Fire V65x Server
* Opteron Advantages Over x86-based Systems