12.   MACHINE-DEPENDENT FACILITIES

This section discusses the facilities of the language for specifying machine-dependent representations for types, specific locations for variables, techniques for using code written in other languages (including assembly language), and configuration capsules which encapsulate machine-dependent information. Other machine-dependent facilities include interrupts (see Section 14.1.4) and low-level I/O (see Section 14.6).

12.1  CONFIGURATION CAPSULES

A capsule with the name "configuration" is called a configuration capsule. A configuration capsule contains information that is dependent upon the particular target system on which a program is to be run. Some of the kinds of data that can be specified in a configuration capsule include:

1. An identification of the target computer and operating system if any. For example,

   

   
   

2. Information about memory. For example,

   

   
   

3. Information about timing (see Section 10.4). For example,

   

   
   

4. Information about I/O devices. For example,

   

   
   

5. Other machine-dependent data of interest.

RULES

When a translation unit contains a capsule invocation declaration which specifies the capsule name configuration, the translator may check the values of various definitions exported (even if they are not made visible) by that capsule, to determine the characteristics of the target system. For example, a compiler that is targeted for PDP-11 may check that the constant machine is defined to have the value "PDP11". The information may also be used, when several translation units are linked together to form an executable program, to verify that all translation units have specified consistent configurations.

EXAMPLES

1. Definition of configuration capsules;

   

   
   
   

2. Use of configuration capsules;

   

   
   
   

12.2  SPECIFICATION OF REPRESENTATIONS

C - identifier   26 - expression

A representation can be specified when a new type is declared (via the type declaration). A representation specifies the physical layout to be used for data items having subtypes of the new type. The layout is specified in terms of the memory of the target computer system.

RULES

When a representation is specified, the underlying type must consist only of built-in types. Each of the representational items are described below. Note that several different representational items may be specified for a given underlying subtype or one of its components.

Bit Numbering

The memory of the target computer is considered to be a sequence of bits. Suppose there are N bits per word. The high order bit of the first word is bit 0. The low order bit of the first word is bit N-1. The high order bit of the m'th word is bit m*N. The low order bit of the m'th word is bit m*N+N-1.

SIZE

SIZE can be specified for any underlying subtype or component. The expression must have type INT and be greater than or equal to zero, and specifies the maximum number of bits to be used to represent the underlying subtype or its components. lf no size is specified, a default implementation-dependent size is used.

ALIGN

ALIGN can only be specified for the entire underlying subtype (i.e., it can not be specified for components). The form

    ALIGN (exp)

specifies that the representation for the underlying subtype is to start at a bit that is at any position p such that p = 0 MOD exp. The form

    ALIGN(exp1 OF exp2)

specifies that the representation for the underlying subtype is to start at a bit that is at any position p such that p = expl MOD exp2. The expressions must all have type INT. The value of expression exp2 must be greater than zero. The value of expl must be in the range 0 .. exp2-1.

OFFSET

OFFSET can only be specified for components of records and unions. The value of the expression is the number of bits from the start of the record or union that the component representation is to start. The expression must have type INT and be greater than or equal to zero. lf an offset is not specified for a record component, then that component starts immediately after the previous component. If an offset is not specified for a union component, then that component starts immediately after the tag. If no offset is specified for the first component of a record, that component starts at the start of the record. If no offset is specified for a union tag, the tag starts at the start of the union.

RECORD

This representational item can only be used for underlying subtypes or for components which have RECORD types. A representation can be specified for each component of the record.

UNION

This representational item can only be used for underlying subtypes or for components which have UNION types. A representation can be specified for each component of the union and a representation can also be specified for the special component named TAG.

ARRAY

This representational item can only be used for underlying subtypes or for components which have ARRAY types. For each index of the array, either NORMAL or NOBOUNDS must be specified. NOBOUNDS indicates that information used for array subscript bounds checking should not be stored.

ENUM

This item specifies that enumeration values are to be represented as the integers 0, 1, ..., max. Since this representation is contiguous, checking for illegal values (e.g., on input) is greatly simplified.

ABSENT

The identifiers must each be names of attributes

PTR

This item specifies how the storage for dynamic variables is to be recovered. This representational item can only be specified for indirect types. FREE indicates that storage will be recovered only when the FREE procedure is explicitly invoked (i.e., there will not be any garbage collection}. If UNCHECKED is specified, no representation will be provided for information used to check tor the X_FREE exception when FREE is invoked for these dynamic variables.

Implementation-Dependent Representation

The representational items described here are only a basic set which will be supported by all implementations. Each implementation may provide additional implementation-dependent representational items.

Restrictions on Representation

A data item is said to have an explicit representation if

1. it is a component (including the .ALL component) of a data item of a user-defined type that has a representational specification, or

2. it is a component of a data item that has an explicit representation.

A data item that has an explicit representation may not be bound to a formal parameter that has a VAR or READONLY binding class. However, such data items can be used in expressions, in CONST or OUT parameter positions, and as targets of the built-in assignment operators.

RED RATIONALE To process data which has been externally generated, the programmer must be able to specify both a high-level description of the data (i.e., their types), so that the appropriate operations can be performed, and a low-level definition of the data (i.e., their representations), so that their values can be correctly retrieved and stored. The RED language complies with the Steelman requirement (SM 11A) for data representation by allowing the user to specify a single physical representation for a new type; the interpretation is that each data item of the type will have that representation.

NOTES

     When a representation is needed for a union where the tag is not to appear explicitly, this can be achieved by using a record with overlapping fields.

EXAMPLES

1. Record layout

   

   
   
   

2. Pointers and array layout

   

   
   
   

3. Record with allocation time determined size and with overlaid fields

   

12.3  LOCATIONS

26 - expression

RULES

A location specification can appear on any variable declaration. The specification

    LOCATION (e1)

will cause the variable to be stored at the memory location which is the value of e1. The expression e1 must have type INT and a value greater than or equal to zero. The specification

    LOCATION (INTERRUPT e2)

can only appear for a variable which has a MAILBOX type, and causes that variable to be associated with hardware interrupt e2 (see Section 14.1.4).

EXAMPLES

12.4  FOREIGN CODE

Foreign code (ie., code written in other languages, including assembly language) can be used as part of a RED program if this feature is supported by the translator. This is achieved by converting the code, via an appropriate utility, into a RED translation unit. Information needed about linkage conventions, types, representation, etc., are supplied as directives to the utility program. Once this has been done, this new translation unit can be exposed by other translation units written in RED as though they also had been written in RED. Note, however, that the translator may have to handle these translation units in a somewhat different fashion than it would handle RED translation units. Note also that some translators may support open (i.e., inline) expansions of foreign code.