2. Target dependency tokens

  1. 2.1. Integer variety representations
    1. 2.1.1. .~rep_var_width
    2. 2.1.2. .~rep_atomic_width
    3. 2.1.3. Floating variety representations
    4. 2.1.4. Non-numeric representations
    5. 2.1.5. Common conversion routines
    6. 2.1.6. .~ptr_to_ptr
    7. 2.1.7. .~ptr_to_int
    8. 2.1.8. .~int_to_ptr
    9. 2.1.9. .~f_to_ptr
    10. 2.1.10. .~ptr_to_f
  2. 2.2. Data model representations
    1. 2.2.1. .~abi_char_width,
      .~abi_short_width,
      .~abi_int_width,
      .~abi_long_width,
      .~abi_longlong_width,
      .~abi_ptr_width
  3. 2.3. Struct representations
    1. 2.3.1. .~abi_min_struct_rep
  4. 2.4. Floating point representations
    1. 2.4.1. .~abi_float_rep,
      .~abi_double_rep,
      .~abi_longdouble_rep
  5. 2.5. Sign
    1. 2.5.1. .~abi_char_is_signed,
      .~abi_bitfield_is_signed
  6. 2.6. Alignment
    1. 2.6.1. .~abi_pv_align

Target dependency tokens provide a common interface to simple constructs where the required detail for any specific architecture can be expressed within TDF, but the detail will be architecture specific. Every installer should have associated with it, a capsule containing the installer specific definitions of all the tokens specificed within §2.

Some of these tokens provide information about the integer and floating point variety representations supported by an installer, in a form that may be used by TDF analysis tools for architecture specific analysis, or by library generation tools when generating an architecture specific version of a library. Other target dependency tokens provide commonly required conversion routines.

It is recommended that these tokens should not be used directly within application programs. They are designed for use within LPI definitions, which can provide a more appropriate interface for applications.

2.1. Integer variety representations

Since TDF specifies integer representations to be twos-complement, the number of bits required to store an integer variety representation fully specifies that representation. The minimum or maximum signed or unsigned integer that can be represented within any variety representation can easily be determined from the number of bits.

2.1.1. .~rep_var_width

w:	NAT
	-> NAT

If w lies within the range of VARIETY sizes supported by the associated installer, rep_var_width(w) will be the number of bits required to store values of VARIETY var_width(b,w), for any BOOL b.

If w is outside the range of VARIETY sizes supported by the associated installer, rep_var_width(w) will be 0.

2.1.2. .~rep_atomic_width

-> NAT

.~rep_atomic_width will be the number of bits required to store values of some VARIETY v such that assign and assign_with_mode are atomic operations if the value assigned has SHAPE integer(v). The TDF specification guarantees existence of such a number.

2.1.3. Floating variety representations

Floating point representations are much more diverse than integers, but we may assume that each installer will support a finite set of distinct representations. For convenience in distinguishing between these representations within architecture specific TDF, the set of distinct representations supported by any specific installer are stated to be ordered into a sequence of non-decreasing memory size. An analysis tool can easily count through this sequence to determine the properties of all supported representations, starting at 1 and using .~rep_fv_width to test for the sequence end.

For all these tokens, unless indicated otherwise, n will lie within the sequence range of supported floating point representations.

2.1.3.1. .~rep_fv
n:	NAT
	-> FLOATING_VARIETY

.~rep_fv(n) will be the FLOATING_VARIETY whose representation is the nth of the sequence of supported floating point representations.

2.1.3.2. .~rep_fv_width
n:	NAT
	-> NAT

If n lies within the sequence range of supported floating point representations, .~rep_fv_width(n) will be the number of bits required to store values of FLOATING_VARIETY .~rep_fv(n).

If n is outside the sequence range of supported floating point representations, .~rep_fv_width(n) will be 0.

2.1.3.3. .~rep_fv_radix
n:	NAT
	-> NAT

.~rep_fv_radix(n) will be the radix used in the representation of values of FLOATING_VARIETY .~rep_fv(n).

2.1.3.4. .~rep_fv_mantissa
n:	NAT
	-> NAT

.~rep_fv_mantissa(n) will be the number of base .~rep_fv_radix(n) digits in the mantissa representation of values of FLOATING_VARIETY .~rep_fv(n).

2.1.3.5. .~rep_fv_min_exp
n:	NAT
	-> NAT

.~rep_fv_min_exp(n) will be the maximum integer m such that (.~rep_fv_radix(n))-m is exactly representable (though not necessarily normalised) by the FLOATING_VARIETY .~rep_fv(n).

2.1.3.6. .~rep_fv_max_exp
n:	NAT
	-> NAT

.~rep_fv_max_exp(n) will be the maximum integer m such that (.~rep_fv_radix(n))m is exactly representable by the FLOATING_VARIETY .~rep_fv( n).

2.1.3.7. .~rep_fv_epsilon
n:	NAT
	-> EXP FLOATING .~rep_fv(n)

.~rep_fv_epsilon(n) will be the smallest strictly positive real x such that (1.0 + x) is exactly representable by the FLOATING_VARIETY .~rep_fv(n).

2.1.3.8. .~rep_fv_min_val
n:	NAT
	-> EXP FLOATING .~rep_fv(n)

.~rep_fv_min_val(n) will be the smallest strictly positive real number that is exactly representable (though not necessarily normalised)) by the FLOATING_VARIETY .~rep_fv(n).

2.1.3.9. .~rep_fv_max_val
n:	NAT
	-> EXP FLOATING .~rep_fv(n)

.~rep_fv_max_val(n) will be the largest real number that is exactly representable by the FLOATING_VARIETY .~rep_fv(n).

2.1.3.10. .~rep_fv_dig
n:	NAT
	-> EXP

.~rep_fv_dig(n) is the number of decimal digits, q, such that any floating point number of FLOATING_VARIETY .~rep_fv(n) with q decimal digits can be rounded into a floating point number (of the same FLOATING_VARIETY) with radix .~rep_fv_radix(n) and back again without change to the q decimal digits.

2.1.3.11. .~rep_fv_max_10_exp
n:	NAT
	-> EXP

.~rep_fv_max_10_exp(n) is the maximum integer such that 10 raised to that power is in the range of representable finite floating-point numbers for the FLOATING_VARIETY .~rep_fv(n).

2.1.3.12. .~rep_fv_min_norm_val
n:	NAT
	-> EXP

.~rep_fv_min_norm_val(n) is the minimum negative integer such that .~rep_fv_radix(n) raised to that power is a normalized floating-point number for the FLOATING_VARIETY .~rep_fv(n). This is equivalent to .~rep_fv_min_val(n), but for a normalised value.

This is intended to correspond to C's FLT_MIN, DBL_MIN and LDBL_MIN values, but does not include the -1 offset present for those macros.

2.1.4. Non-numeric representations

2.1.4.1. .~ptr_width
-> NAT

.~ptr_width will be the minimum .~rep_var_width(w) for any w such that any pointer to any alignment may be converted to an integer of VARIETY var_width(b,w), for some BOOL b, and back again without loss of information, using the conversions .~ptr_to_int and .~int_to_ptr (q.v.).

2.1.4.2. .~best_div
-> NAT

.~best_div is 1 or 2 to indicate preference for class 1 or class 2 division and modulus (as defined in the TDF Specification). This token would be used in situations where either class is valid but must be used consistently.

2.1.4.3. .~little_endian
-> BOOL

.~little_endian is a property of the relationship between different variety representations and arrays. If an array of a smaller variety can be mapped onto a larger variety, and .~little_endian is true, then smaller indices of the smaller variety array map onto smaller ranges of the larger variety. If .~little_endian is false, no such assertion can be made.

2.1.5. Common conversion routines

This subsection contains a set of conversion routines between values of different shapes, that are not required to have any specific meaning apart from reversability. If the storage space requirements for the two shapes are identical, the conversion can usually be achieved without change of representation. When that is the case, and if the two shapes can be stored at a common alignment, the conversion can simply be achieved by assignment via a common union, which will ensure the required alignment consistency.

2.1.6. .~ptr_to_ptr

a1:	ALIGNMENT
a2:	ALIGNMENT
p:	EXP POINTER(a1)
	-> EXP POINTER(a2)

.~ptr_to_ptr converts pointers from one pointer shape to another.

If p is any pointer with alignment a1, then .~ptr_to_ptr (a2, a1, .~ptr_to_ptr(a1, a2, p)) shall result in the same pointer p, provided that the number of bits required to store a pointer with alignment a2 is not less than that required to store a pointer with alignment a1.

2.1.7. .~ptr_to_int

a:	ALIGNMENT
v:	VARIETY
p:	EXP POINTER(a)
	-> EXP INTEGER(v)

.~ptr_to_int converts a pointer to an integer. The result is undefined if the VARIETY v is insufficient to distinguish between all possible distinct pointers p of alignment a.

2.1.8. .~int_to_ptr

v:	VARIETY
a:	ALIGNMENT
i:	EXP INTEGER(v)
	-> EXP POINTER(a)

.~int_to_ptr converts an integer to a pointer. The result is undefined unless the integer i was obtained without modification from some pointer using .~ptr_to_int with the same variety and alignment arguments.

If p is any pointer with alignment a, and v is var_width(b, .~ptr_width) for some BOOL b, then .~int_to_ptr(v, a, .~ptr_to_int (a, v, p)) shall result in the same pointer p.

2.1.9. .~f_to_ptr

a:	ALIGNMENT
fn:	EXP PROC
	-> EXP POINTER(a)

.~f_to_ptr converts a procedure to a pointer. The result is undefined except as required for consistency with .~ptr_to_f.

2.1.10. .~ptr_to_f

a:	ALIGNMENT
p:	EXP POINTER(a)
	-> EXP PROC

.~ptr_to_f converts a pointer to a procedure. The result is undefined unless the pointer p was obtained without modification from some procedure f using .~f_to_ptr(a, f). The same procedure f is delivered.

2.2. Data model representations

2.2.1. .~abi_char_width,
.~abi_short_width,
.~abi_int_width,
.~abi_long_width,
.~abi_longlong_width,
.~abi_ptr_width

-> NAT

These represent the number of bits for the respectively named sizes belonging to the target machine's data model.

Note that these names (char, short etc.) are not C types; they are the names defined by a data model. These are provided as an abstraction, so that their respective C (and other LPI) tokens such as .~char_width may be mapped to the data model in such a way that the underlying data model may be easily substituted.

2.3. Struct representations

2.3.1. .~abi_min_struct_rep

Minimum struct representation size.

2.4. Floating point representations

2.4.1. .~abi_float_rep,
.~abi_double_rep,
.~abi_longdouble_rep

-> NAT

These represent the sequence number for the respectively named floating point tokens belonging to the target machine's floating point representations.

Note that these names (float, double etc.) are not C types; they are the names defined by a model of floating point representations. These are provided as an abstraction, so that their respective C (and other LPI) tokens such as .~char_width may be mapped to the data model in such a way that the underlying representation may be easily substituted.

The sequence numbers correspond to the values defined under §2.1.3.

2.5. Sign

2.5.1. .~abi_char_is_signed,
.~abi_bitfield_is_signed

-> BOOL

2.6. Alignment

2.6.1. .~abi_pv_align

-> ALIGNMENT