TDF Guide, Issue 4.0
January 1998
There are facilities to allow extensions to the number of constructors,
so it is not quite as simple as this
The "tld" UNITs gives usage information for namess to aid
the linker, tld, to discover which namess have definitions and some
usage information. The C producer also optionally constructs "diagnostics"
UNITs (to give run-time diagnostic information).
There is a similar distinction between tags introduced to be locals
of a procedure using identify and variable (see
section 5.3.1)
Note that is not generally true for C bitfields; most C ABIs have
(different) rules for putting in padding bits depending on the size
of the bitfield and its relation with the natural alignments. This
is a fruitful source of errors in data exchange between different
C ABIs For more on similar limitations of bitfields in TDF (see
Assigning and extracting bitfields).
The vararg construction in C are implemented by giving more actuals
than formals; the extra parameters are accessed by offset arithmetic
with a pointer to a formal, using parameter_alignment to pad the offsets.
If a formal parameter is to be used in this way, it should be marked
as having out_par ACCESS in its corresponding TAGSHACC in callers_intro.
However see also initial_value in section
3.2
Exercise for the reader: what are the SORTs of these parameters?
The current C producer does this for some of the constructs, but not
in any systematic manner; perhaps it will change.
The order-specifying constructors are conditional, identify, repeat,
labelled, sequence and variable
A sufficient condition for not side-effecting in this sense is that
there are no apply_procs or local_allocs in E; that any assignments
in E are to variables defined in E; and that any branches in E are
to labels defined in conditionals in E
There are analogous rules for labelled and repeat with unused LABELs.
This has to be modified if B contains any uses of local_free_all or
last_local.
However, we may find that the mapping of a constraint allows extra
relationships for a class of architectures which do not hold in all
generality; this may mean that some constructions are defined on this
class while still being undefined in others (see section
13).
I could equally have given simply shape_offset(sh_int) for S_i, but
the above formulation is more uniform with respect to selection OFFSETs.
For most architectures, these definition are dependent only on a few
constants such as the maximum length of bitfield., expessed as tokens
for the target. The precise specification of such target dependent
tokens is of current interest outside the scope of this document.
Part of the TenDRA Web.
Crown
Copyright © 1998.