4. TDF Interface tokens
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 -> EXPs
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 SHAPE
s s
must be the appropriate SHAPE
s 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
: SHAPEs2
: 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 OFFSET
s 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 ALIGNMENT
s 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
: SHAPEs2
: 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 OFFSET
s 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 ALIGNMENT
s appropriate to the make_general_proc
(as specified by current_env
).