Low-level system information

Machine interface

This section describes the processor-specific information for the S/390 processors.

Processor architecture

[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.)

Data representation

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.

Figure 1. Bit and byte numbering in halfwords

Figure 2. Bit and byte numbering in words

Figure 3. Bit and byte numbering in doublewords

Fundamental types

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

signed char

char

unsigned char

1

1

byte

Short

signed short

short

unsigned short

2

2

halfword

Integer

signed int

int

unsigned int

enum

signed long

long

unsigned long

4

4

word

Long long

signed long long

long long

unsigned long long

8

8

doubleword

Pointer

any-type *

any-type (*) ()

4

4

unsigned word

Floating point

float

4

4

single precision (IEEE)

double

8

8

double precision (IEEE)

long

double¹

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 and unions

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.

Table 2.

struct {

         char c;

};

Figure 4. Structure smaller than a word

Table 3.

struct {

         char c;

         char d;

         short s;

         long n;

};

Figure 5. No padding

Table 4.

struct {

         char c;

         short s;

};

Figure 6. Internal padding

Table 5.

struct {

         char c;

         double d;

         short s;

};

Figure 7. Internal and tail padding

Table 6.

union  {

         char c;

         short s;

         int   j;

};

Figure 8. Union padding

Bit-fields

C struct and union definitions may have "bit-fields," defining integral objects with a specified number of bits (see Table 7).

Table 7. Bit fields

Bit-field type

Width n

Range

signed char



char



unsigned char

1 to 8

-2���¹ to

2��¹ - 1



0 to 2� - 1



0 to 2� - 1

signed short



short



unsigned short

1 to 16

-2��¹ to

2��¹ - 1



0 to 2� - 1



0 to 2� - 1

signed int



int



unsigned int



enum



signed long



long



unsigned long

1 to 32

-2��¹ to

2��¹ - 1



0 to 2� - 1



0 to 2� - 1



0 to 2� - 1



-2��¹ to 2��¹ - 1



0 to 2� - 1



0 to 2� - 1

signed long long



long long



unsigned long long

1 to 64

-2��¹ to

2��¹ - 1



0 to 2� - 1



0 to 2� -

1

"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.

Figure 9. Bit numbering

Figure 10. Left-to-right allocation

Figure 11. Boundary alignment

Figure 12. Storage unit sharing

Figure 13. Union allocation

Figure 14. Unnamed bit fields