Solaris SPARC to Solaris x86 Porting Guide

Compilers add padding bytes into structures so that all values are appropriately aligned. The amount

of padding added is a function of the structure, the processor's architecture, and the compiler.

Because of this, structures may increase in size when code is ported to a processor architecture with

more bits (for example, from 16 to 32, or from 32 to 64).

For example, if a platform requires that words (assume 2 bytes) must be aligned on 2-byte

boundaries, and that dwords (assume 4 bytes) must be aligned on 4-byte boundaries, then the

structure is:

0 word_type

2 (padding)

4 dword_type

sizeof(BITMAP) == 8

In contrast, on a platform not requiring any special alignment, the structure is:

0 word_type

2 dword_type

sizeof(BITMAP) == 6

This difference might cause some corruption. However, in most cases, issues do not occur when

porting applications from the Solaris SPARC to x86 environments,. The Solaris OS compilation system

manages most alignment and structure padding.

Floating point operation difference sin x86 operating systems

Issue: The floating-point registers are 80-bits wide, while in the SPARC systems, the floating point

registers are 64-bits wide. Due to this inconsistency, the computation results might differ because

intermediate results of arithmetic computations can be in extended precision. For more details, see the

Numerical Computation Guide.

Solution: The -fstore compiler flag minimizes these discrepancies. However, using the -fstore

flag introduces issues in performance.

Issue: Each time a single or double precision floating-point number is loaded or stored in the x86

operating systems, a conversion to or from double extended precision occurs. Loads and stores of

floating-point numbers can cause exceptions. In SPARC systems, a single or double precision floating-

point number is always loaded or stored as single or double precision.

Solution: The -fprecision initializes the rounding-precision mode bits in the floating-point control

word to single (24 bits), double (53 bits), or extended (64 bits), respectively. The default floating-point

rounding-precision mode is extended. On x86 operating systems, only the precision, not exponent,

range is affected by the setting of floating-point rounding precision mode.

Issue: Gradual underflow is implemented entirely in hardware. As opposed to SPARC systems, x86

operating systems lack a nonstandard mode.

Solution: Use the option -fnonstd on x86 operating systems. This causes nonstandard initialization

of floating-point arithmetic hardware. In addition, the -fnonstd option causes hardware traps to be

enabled for floating-point overflow, division by zero, and invalid operations exceptions.

The fpversion utility is not provided in x86 operating systems. In SPARC systems, the fpversion

utility distributed with the compilers identifies the installed CPU and estimates the processor and

system bus clock speeds. fpversion determines the CPU and FPU types by interpreting the

identification information stored by the CPU and FPU. It estimates their clock speeds by timing a loop

that executes simple instructions that run in a predictable amount of time. The loop is executed many

times to increase the accuracy of the timing measurements. For this reason, fpversion is not