4. TDF Interface tokens

  1. 4.1. Exception handling
    1. 4.1.1. ~Throw
    2. 4.1.2. ~Set_signal_handler
    3. 4.1.3. ~Sync_handler
  2. 4.2. TDF Diagnostic Specification
    1. 4.2.1. ~exp_to_source, ~diag_id_scope, ~diag_type_scope, ~diag_tag_scope
  3. 4.3. Accessing variable parameter lists
    1. 4.3.1. ~va_list
    2. 4.3.2. ~__va_start
    3. 4.3.3. ~va_arg
    4. 4.3.4. ~va_end
    5. 4.3.5. ~next_caller_offset
    6. 4.3.6. ~next_callee_offset

A very few specifically named tokens are referred to within the TDF specification, which are required to complete the ability to use certain TDF constructs. Responsibility for providing appropriate definitions for these tokens is indicated with the specifications below.

Similarly, a few tokens are specified within the TDF Diagnostic Specification.

4.1. Exception handling

4.1.1. ~Throw

n:	NAT
	-> EXP BOTTOM

The EXP e defined as the body of this token will be evaluated on occurrence of any error whose ERROR_TREATMENT is trap. The type of error can be determined within e from the NAT n, which will be error_val(ec) for some ERROR_CODE ec. The token definition body e will typically consist of a long_jump to some previously set exception handler.

Exception handling using trap and ~Throw will usually be determined by producers for languages that specify their own exception handling semantics. Responsibility for the ~Throw token definition will therefore normally rest with producers, by including this token within the producer specific LPI.

4.1.2. ~Set_signal_handler

 -> EXP OFFSET (locals_alignment, locals_alignment)

~Set_signal_handler must be applied before any use of the ERROR_TREATMENT trap, to indicate the need for exception trapping. Responsibility for the ~Set_signal_handler token definition will rest with installers. Responsibility for applying it will normally rest with producers.

The resulting offset value will contain the amount of space beyond any stack limit, which must be reserved for use when handling a stack_overflow trap raised by exceeding that limit.

4.1.3. ~Sync_handler

 -> EXP TOP

~Sync_handler delays subsequent processing until any pending exceptions have been raised, as necessary to synchronise exception handler modification. It must be applied immediately prior to any action that modifies the effect of ~Throw, such as assignment to a variable holding an exception handler as long_jump destination Responsibility for the ~Sync_handler token definition will rest with installers. Responsibility for applying it will normally rest with producers.

4.2. TDF Diagnostic Specification

The TDF Diagnostic Specification is a separate document which describes an extension to TDF, optionally used to provide program diagnostic information that can be transformed by installers to the form required by popular platform-specific debuggers. This extension cannot be considered fully developed and is therefore not included as part of standard TDF. Its use for other than DRA's C producer has not been considered.

4.2.1. ~exp_to_source, ~diag_id_scope, ~diag_type_scope, ~diag_tag_scope

bdy:	EXP
... :	 ...
	-> EXP

Each of these four tokens has several arguments of which the first, bdy, is an EXP. In each case the default definition body, when no diagnostic information is required, is simply bdy. Note that this description is quite sufficient to enable installers to ignore any diagnostic information that may be included in produced TDF, without needing any further knowledge of the TDF Diagnostic Specification.

4.3. Accessing variable parameter lists

Installers should provide token definitions for the tokens listed in this section.

4.3.1. ~va_list

 -> SHAPE

This is the SHAPE of a variable capable of holding state information used for stepping through the anonymous parameters of a procedure created by make_proc.

4.3.2. ~__va_start

p:	EXP POINTER var_param_alignment
	-> EXP ~va_list

If t is the TAG introduced by var_intro OPTION(TAGACC) in make_proc, then the token application ~__va_start(obtain_tag(t)) will provide the initial value for a local variable to be used for stepping through the anonymous parameters of the procedure, starting with the first actual parameter (if any) that does not have a corresponding entry in the make_proc params_intro list.

4.3.3. ~va_arg

v:	EXP POINTER (alignment(~va_list))
s:	SHAPE
	-> EXP s

If v is the variable initialised by ~__va_start (see above), then successive token applications ~va_arg(v,s) will deliver the anonymous parameter values in turn. The successive SHAPEs s must be the appropriate SHAPEs for the successive parameters.

4.3.4. ~va_end

v:	EXP POINTER (alignment(~va_list))
	-> EXP TOP

If v is a variable initialised by ~__va_start, the token application ~va_end(v) indicates that no further use will be made of v.

4.3.5. ~next_caller_offset

o1:	EXP OFFSET (fa,parameter_alignment(s1))
s1:	SHAPE
s2:	SHAPE
	-> EXP OFFSET (fa,parameter_alignment(s2))

~next_caller_offset is used to provide access to successive elements of the caller_params of an apply_general_proc, by delivering successive OFFSETs of their positions relative to the environment pointer created by that procedure application. Both the apply_general_proc and associated make_general_proc will include PROCPROPS var_callers.

o1 will be the OFFSET for a caller_params element of SHAPE s1, and will be derived either from env_offset for a TAG introduced by caller_intro of the make_general_proc , or from a previous application of ~next_caller_offset. s2 will be the SHAPE of the subsequent caller_params element, whose OFFSET is delivered. fa will include the set union of ALIGNMENTs appropriate to the make_general_proc (as specified by current_env).

4.3.6. ~next_callee_offset

o1:	EXP OFFSET (fa,parameter_alignment(s1))
s1:	SHAPE
s2:	SHAPE
	-> EXP OFFSET (fa,parameter_alignment(s2))

~next_callee_offset is used to provide access to successive elements of the CALLEES of an apply_general_proc or tail_call, by delivering successive OFFSETs of their positions relative to the environment pointer created by that procedure application. Both the procedure application and associated make_general_proc will include PROCPROPS var_callees.

o1 will be the OFFSET for a CALLEES element of SHAPE s1, and will be derived either from env_offset for a TAG introduced by callee_intro of the make_general_proc, or from a previous application of ~next_callee_offset. s2 will be the SHAPE of the subsequent CALLEES element, whose OFFSET is delivered. fa will include the set union of ALIGNMENTs appropriate to the make_general_proc (as specified by current_env ).