S/390 ELF Application Binary Interface Supplement | ||
---|---|---|
<<< Previous | Next >>> |
This section describes the processor-specific information for the S/390 processors.
[ESA/390 Principles of Operation] (SA22–7201) defines the ESA/390 architecture.
Programs intended to execute directly on the processor use the ESA/390 instruction set, and the instruction encoding and semantics of the architecture.
An application program can assume that all instructions defined by the architecture that are neither privileged nor optional exist and work as documented.
To be ABI-conforming the processor must implement the instructions of the architecture, perform the specified operations, and produce the expected results. The ABI neither places performance constraints on systems nor specifies what instructions must be implemented in hardware. A software emulation of the architecture could conform to the ABI.
There are some instructions in the ESA/390 architecture which are described as 'optional'. Linux for S/390 requires some of these to be available; in particular:
additional floating point facilities,
compare and move extended,
immediate and relative instructions,
string instructions.
The ABI guarantees that these instructions are present. In order to comply with the ABI the operating system must emulate these instructions on machines which do not support them in the hardware. Other instructions are not available in some current models; programs using these instructions do not conform to the S/390 ABI and executing them on machines without the extra capabilities will result in undefined behavior.
In the ESA/390 architecture a processor runs in big-endian mode. (See the Section called Byte ordering.)
The architecture defines an 8-bit byte, a 16-bit halfword, a 32-bit word and a 64-bit doubleword. Byte ordering defines how the bytes that make up halfwords, words and doublewords are ordered in memory. Most significant byte (MSB) ordering, or "Big-Endian" as it is sometimes called, means that the most significant byte of a structure is located in the lowest addressed byte position in a storage unit (byte 0).
Figure 1 to Figure 3 illustrate the conventions for bit and byte numbering within storage units of various widths. These conventions apply to both integer data and floating-point data, where the most significant byte of a floating-point value holds the sign and the exponent (or at least the start of the exponent). The figures show big-endian byte numbers in the upper left corners and bit numbers in the lower corners.
Table 1 shows how ANSI C scalar types correspond to those of the S/390 processor. For all types a NULL pointer has the value zero (binary).
Table 1. Scalar types
Type | ANSI C | sizeof (bytes) | Alignment | type (S/390) |
---|---|---|---|---|
Character | 1 | 1 | byte | |
Short | 2 | 2 | halfword | |
Integer | 4 | 4 | word | |
Long long | 8 | 8 | doubleword | |
Pointer | 4 | 4 | unsigned word | |
Floating point | 4 | 4 | single precision (IEEE) | |
8 | 8 | double precision (IEEE) | ||
16 | 16 | extended precision (IEEE) | ||
¹Compilers and systems may implement the long double data type in some other way, for performance reasons, using a compiler option. Examples of such formats could be two successive doubles or even a single double. Such usage does not conform to this ABI however, and runs the risk of passing a wrongly formatted floating-point number to another function as an argument. Programs using other formats should transform long double floating-point numbers to a conforming format before passing them. |
Aggregates (structures and arrays) and unions assume the alignment of their most strictly aligned component, that is, the component with the largest alignment. The size of any object, including aggregates and unions, is always a multiple of the alignment of the object. An array uses the same alignment as its elements. Structure and union objects may require padding to meet size and alignment constraints:
An entire structure or union object is aligned on the same boundary as its most strictly aligned member.
Each member is assigned to the lowest available offset with the appropriate alignment. This may require internal padding, depending on the previous member.
If necessary, a structure's size is increased to make it a multiple of the structure's alignment. This may require tail padding if the last member does not end on the appropriate boundary.
In the following examples (Figure 4 to Figure 8), member byte offsets (for the big-endian implementation) appear in the upper left corners.
C struct and union definitions may have "bit-fields," defining integral objects with a specified number of bits (see Table 7).
"Plain" bit-fields (that is, those neither signed nor unsigned) always have non-negative values. Although they may have type short, int or long (which can have negative values), bit-fields of these types have the same range as bit-fields of the same size with the corresponding unsigned type. Bit-fields obey the same size and alignment rules as other structure and union members, with the following additions:
Bit-fields are allocated from left to right (most to least significant).
A bit-field must entirely reside in a storage unit appropriate for its declared type. Thus, a bit-field never crosses its unit boundary.
Bit-fields must share a storage unit with other structure and union members (either bit-field or non-bit-field) if and only if there is sufficient space within the storage unit.
Unnamed bit-fields' types do not affect the alignment of a structure or union, although an individual bit-field's member offsets obey the alignment constraints. An unnamed, zero-width bit-field shall prevent any further member, bit-field or other, from residing in the storage unit corresponding to the type of the zero-width bit-field.
The following examples (Figure 9 through Figure 14) show structure and union member byte offsets in the upper left corners. Bit numbers appear in the lower corners.
<<< Previous | Home | Next >>> |
Preface | Function calling sequence |