Rev 2 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>Footnotes</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<A NAME=S99>
<H1>TDF Guide, Issue 4.0 </H1>
<H3>January 1998</H3>
<IMG SRC="../images/no_next.gif" ALT="next section">
<IMG SRC="../images/no_prev.gif" ALT="previous section">
<A HREF="guide1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>
<H2><A NAME=70>Footnote 1</A></H2>
There are facilities to allow extensions to the number of constructors,
so it is not quite as simple as this<P>
<HR>
<H2><A NAME=71>Footnote 2</A></H2>
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).<P>
<HR>
<H2><A NAME=72>Footnote 3</A></H2>
There is a similar distinction between tags introduced to be locals
of a procedure using identify and variable (see
<A HREF="guide7.html#35">section 5.3.1</A>)<P>
<HR>
<H2><A NAME=73>Footnote 4</A></H2>
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
<A HREF="guide9.html#16">Assigning and extracting bitfields</A>).<P>
<HR>
<H2><A NAME=74>Footnote 5</A></H2>
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.<P>
<HR>
<H2><A NAME=75>Footnote 6</A></H2>
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 <I>callers_intro</I>.
<HR>
<H2><A NAME=76>Footnote 7</A></H2>
However see also initial_value in <A HREF="guide5.html#19">section
3.2</A><P>
<HR>
<H2><A NAME=78>Footnote 8</A></H2>
Exercise for the reader: what are the SORTs of these parameters?<P>
The current C producer does this for some of the constructs, but not
in any systematic manner; perhaps it will change.<P>
<HR>
<H2><A NAME=79>Footnote 9</A></H2>
The order-specifying constructors are conditional, identify, repeat,
labelled, sequence and variable<P>
<HR>
<H2><A NAME=80>Footnote 10</A></H2>
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<P>
<HR>
<H2><A NAME=81>Footnote 11</A></H2>
There are analogous rules for labelled and repeat with unused LABELs.<P>
<HR>
<H2><A NAME=82>Footnote 12</A></H2>
This has to be modified if B contains any uses of local_free_all or
last_local.<P>
<HR>
<H2><A NAME=83>Footnote 13</A></H2>
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 <A HREF="guide15.html#0">section
13</A>).<P>
<HR>
<H2><A NAME=84>Footnote 14</A></H2>
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.<P>
<HR>
<H2><A NAME=85>Footnote 15</A></H2>
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.<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>