| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>Structure of TDF</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<H1><A NAME=S4>TDF Specification, Issue 4.0</A></H1>
|
|
|
8 |
<H3>January 1998</H3>
|
|
|
9 |
<A HREF="spec6.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
|
|
|
10 |
<A HREF="spec4.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
11 |
<A HREF="spec1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
12 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
13 |
</A>
|
|
|
14 |
<A HREF="spec12.html"><IMG SRC="../images/index.gif" ALT="document index"></A>
|
|
|
15 |
<P>
|
|
|
16 |
<HR>
|
|
|
17 |
<DL>
|
|
|
18 |
<DT><A HREF="#S5"><B>2.1</B> - The Overall Structure</A><DD>
|
|
|
19 |
<DT><A HREF="#S6"><B>2.2</B> - Tokens</A><DD>
|
|
|
20 |
<DT><A HREF="#S7"><B>2.3</B> - Tags</A><DD>
|
|
|
21 |
<DT><A HREF="#S8"><B>2.4</B> - Extending the format</A><DD>
|
|
|
22 |
</DL>
|
|
|
23 |
<HR>
|
|
|
24 |
<H1>2. Structure of TDF</H1>
|
|
|
25 |
<A NAME=M1>Each piece of TDF program is classified as being of a particular
|
|
|
26 |
<CODE>SORT</CODE>. Some pieces of TDF are
|
|
|
27 |
<CODE>LABEL</CODE>s, some are <CODE>TAG</CODE>s, some are
|
|
|
28 |
<CODE>ERROR_TREATMENT</CODE>s and so on (to list some of the more
|
|
|
29 |
transparently named <CODE>SORT</CODE>s). The <CODE>SORT</CODE>s of
|
|
|
30 |
the arguments and result of each construct of the TDF format are specified.
|
|
|
31 |
For instance, <I>plus</I> is defined to have three arguments - an
|
|
|
32 |
<CODE>ERROR_TREATMENT</CODE> and two <CODE>EXP</CODE>s (short for
|
|
|
33 |
"expression") - and to produce an <CODE>EXP</CODE>;
|
|
|
34 |
<I>goto</I> has a single <CODE>LABEL</CODE> argument and produces
|
|
|
35 |
an
|
|
|
36 |
<CODE>EXP</CODE>. The specification of the <CODE>SORT</CODE>s of the
|
|
|
37 |
arguments and results of each construct constitutes the syntax of
|
|
|
38 |
the TDF format. When TDF is represented as a parsed tree it is structured
|
|
|
39 |
according to this syntax. When it is constructed and read it is in
|
|
|
40 |
terms of this syntax.
|
|
|
41 |
<P>
|
|
|
42 |
<A NAME=S5>
|
|
|
43 |
<H2>2.1. <A NAME=2>The Overall Structure</H2>
|
|
|
44 |
<A NAME=M3>A separable piece of TDF is called a <CODE>CAPSULE</CODE>.
|
|
|
45 |
A producer generates a <CODE>CAPSULE</CODE>; the TDF linker links
|
|
|
46 |
<CODE>CAPSULE</CODE>s together to form a <CODE>CAPSULE</CODE>; and
|
|
|
47 |
the final translation process turns a <CODE>CAPSULE</CODE> into an
|
|
|
48 |
object file.
|
|
|
49 |
<P>
|
|
|
50 |
The structure of capsules is designed so that the process of linking
|
|
|
51 |
two or more capsules consists almost entirely of copying large byte-aligned
|
|
|
52 |
sections of the source files into the destination file, without changing
|
|
|
53 |
or even examining these sections. Only a small amount of interface
|
|
|
54 |
information has to be modified and this is made easily accessible.
|
|
|
55 |
The translation process only requires an extra indirection to account
|
|
|
56 |
for this interface information, so it is also fast. The description
|
|
|
57 |
of TDF at the capsule level is almost all about the organisation of
|
|
|
58 |
the interface information.
|
|
|
59 |
<P>
|
|
|
60 |
There are three major kinds of entity which are used inside a capsule
|
|
|
61 |
to name its constituents. The first are called tags; they are used
|
|
|
62 |
to name the procedures, functions, values and variables which are
|
|
|
63 |
the components of the program. The second are called tokens; they
|
|
|
64 |
identify pieces of TDF which can be used for substitution - a little
|
|
|
65 |
like macros. The third are the alignment tags, used to name alignments
|
|
|
66 |
so that circular types can be described. Because these internal names
|
|
|
67 |
are used for linking pieces of TDF together, they are collectively
|
|
|
68 |
called <I>linkable entities</I>. The interface information relates
|
|
|
69 |
these linkable entities to each other and to the world outside the
|
|
|
70 |
capsule.
|
|
|
71 |
<P>
|
|
|
72 |
The most important part of a capsule, the part which contains the
|
|
|
73 |
real information, consists of a sequence of groups of units. Each
|
|
|
74 |
group contains units of the same kind, and all the units of the same
|
|
|
75 |
kind are in the same group. The groups always occur in the same order,
|
|
|
76 |
though it is not necessary for each kind to be present.
|
|
|
77 |
<CENTER>
|
|
|
78 |
<BR><IMG SRC="../images/capsule4.gif"><BR>
|
|
|
79 |
</CENTER>
|
|
|
80 |
<P>
|
|
|
81 |
<A NAME=M4>The order is as follows:
|
|
|
82 |
<UL>
|
|
|
83 |
<LI><A NAME=M5><I>tld</I> unit. Every capsule has exactly one tld
|
|
|
84 |
unit. It gives information to the TDF linker about those items in
|
|
|
85 |
the capsule which are visible externally.<P>
|
|
|
86 |
<LI><I>versions</I> unit. These units contain information about the
|
|
|
87 |
versions of TDF used. Every capsule will have at least one such unit.<P>
|
|
|
88 |
<LI><A NAME=M6><I>tokdec</I> units. These units contain declarations
|
|
|
89 |
for tokens. They bear the same relationship to the following tokdef
|
|
|
90 |
units that C declarations do to C definitions. However, they are not
|
|
|
91 |
necessary for the translator, and the current ANSI C producer does
|
|
|
92 |
not provide them by default.<P>
|
|
|
93 |
<LI><A NAME=M7><I>tokdef</I> units. These units contain definitions
|
|
|
94 |
of tokens.<P>
|
|
|
95 |
<LI><A NAME=M8><I>aldef</I> units. These units give the definitions
|
|
|
96 |
of alignment tags.<P>
|
|
|
97 |
<LI><I>diagtype</I> units. These units give diagnostic information
|
|
|
98 |
about types.<P>
|
|
|
99 |
<LI><A NAME=M9><I>tagdec</I> units. These units contain declarations
|
|
|
100 |
of tags, which identify values, procedures and run-time objects in
|
|
|
101 |
the program. The declarations give information about the size, alignment
|
|
|
102 |
and other properties of the values. They bear the same relationship
|
|
|
103 |
to the following tagdef units that C declarations do to C definitions.<P>
|
|
|
104 |
<LI><I>diagdef</I> units. These units give diagnostic information
|
|
|
105 |
about the values and procedures defined in the capsule.<P>
|
|
|
106 |
<LI><A NAME=M10><I>tagdef</I> units. These units contain the definitions
|
|
|
107 |
of tags, and so describe the procedures and the values they manipulate.<P>
|
|
|
108 |
<LI><I>linkinfo</I> units. These units give information about the
|
|
|
109 |
linking of objects.
|
|
|
110 |
</UL>
|
|
|
111 |
This organisation is imposed to help installers, by ensuring that
|
|
|
112 |
the information needed to process a unit has been provided before
|
|
|
113 |
that unit arrives. For example, the token definitions occur before
|
|
|
114 |
any tag definition, so that, during translation, the tokens may be
|
|
|
115 |
expanded as the tag definitions are being read (in a capsule which
|
|
|
116 |
is ready for translation all tokens used must be defined, but this
|
|
|
117 |
need not apply to an arbitrary capsule).
|
|
|
118 |
<P>
|
|
|
119 |
The tags and tokens in a capsule have to be related to the outside
|
|
|
120 |
world. For example, there might be a tag standing for <I>printf</I>,
|
|
|
121 |
used in the appropriate way inside the capsule. When an object file
|
|
|
122 |
is produced from the capsule the identifier <I>printf</I> must occur
|
|
|
123 |
in it, so that the system linker can associate it with the correct
|
|
|
124 |
library procedure. In order to do this, the capsule has a table of
|
|
|
125 |
tags at the capsule level, and a set of external links which provide
|
|
|
126 |
external names for some of these tags.
|
|
|
127 |
<CENTER>
|
|
|
128 |
<BR><IMG SRC="../images/capsule1.gif"><BR>
|
|
|
129 |
</CENTER>
|
|
|
130 |
<P>
|
|
|
131 |
In just the same way, there are tables of tokens and alignment tags
|
|
|
132 |
at the capsule level, and external links for these as well.
|
|
|
133 |
<P>
|
|
|
134 |
The tags used inside a unit have to be related to these capsule tags,
|
|
|
135 |
so that they can be properly named. A similar mechanism is used, with
|
|
|
136 |
a table of tags at the unit level, and links between these and the
|
|
|
137 |
capsule level tags.
|
|
|
138 |
<CENTER>
|
|
|
139 |
<BR><IMG SRC="../images/capsule2.gif"><BR>
|
|
|
140 |
</CENTER>
|
|
|
141 |
<P>
|
|
|
142 |
Again the same technique is used for tokens and alignment tags.
|
|
|
143 |
<P>
|
|
|
144 |
It is also necessary for a tag used in one unit to refer to the same
|
|
|
145 |
thing as a tag in another unit. To do this a tag at the capsule level
|
|
|
146 |
is used, which may or may not have an external link.
|
|
|
147 |
<CENTER>
|
|
|
148 |
<BR><IMG SRC="../images/capsule3.gif"><BR>
|
|
|
149 |
</CENTER>
|
|
|
150 |
<P>
|
|
|
151 |
The same technique is used for tokens and alignment tags.
|
|
|
152 |
<P>
|
|
|
153 |
So when the TDF linker is joining two capsules, it has to perform
|
|
|
154 |
the following tasks:
|
|
|
155 |
<UL>
|
|
|
156 |
<LI>It creates new sets of capsule level tags, tokens and alignment
|
|
|
157 |
tags by identifying those which have the same external name, and otherwise
|
|
|
158 |
creating different entries.<P>
|
|
|
159 |
<LI>It similarly joins the external links, suppressing any names which
|
|
|
160 |
are no longer to be external.<P>
|
|
|
161 |
<LI>It produces new link tables for the units, so that the entities
|
|
|
162 |
used inside the units are linked to the new positions in the capsule
|
|
|
163 |
level tables.<P>
|
|
|
164 |
<LI>It re-organises the units so that the correct order is achieved.
|
|
|
165 |
</UL>
|
|
|
166 |
This can be done without looking into the interior of the units (except
|
|
|
167 |
for the <I>tld</I> unit), simply copying the units into their new
|
|
|
168 |
place.
|
|
|
169 |
<P>
|
|
|
170 |
During the process of installation the values associated with the
|
|
|
171 |
linkable entities can be accessed by indexing into an array followed
|
|
|
172 |
by one indirection. These are the kinds of object which in a programming
|
|
|
173 |
language are referred to by using identifiers, which involves using
|
|
|
174 |
hash tables for access. This is an example of a general principle
|
|
|
175 |
of the design of TDF; speed is required in the linking and installing
|
|
|
176 |
processes, if necessary at the expense of time in the production of
|
|
|
177 |
TDF.
|
|
|
178 |
<P>
|
|
|
179 |
<A NAME=S6>
|
|
|
180 |
<H2>2.2. Tokens</H2>
|
|
|
181 |
<A NAME=M11>Tokens are used (applied) in the TDF at the point where
|
|
|
182 |
substitutions are to be made. Token definitions provide the substitutions
|
|
|
183 |
and usually reside on the target machine and are linked in there.
|
|
|
184 |
<P>
|
|
|
185 |
A typical token definition has parameters from various
|
|
|
186 |
<CODE>SORT</CODE>s and produces a result of a given <CODE>SORT</CODE>.
|
|
|
187 |
As an example of a simple token definition, written here in a C-like
|
|
|
188 |
notation, consider the following.
|
|
|
189 |
<PRE>
|
|
|
190 |
<I>EXP ptr_add (EXP par0, EXP par1, SHAPE par2)
|
|
|
191 |
{
|
|
|
192 |
add_to_ptr(
|
|
|
193 |
par0,
|
|
|
194 |
offset_mult(
|
|
|
195 |
offset_pad(
|
|
|
196 |
alignment(par2),
|
|
|
197 |
shape_offset(par2)),
|
|
|
198 |
par1))
|
|
|
199 |
}</I>
|
|
|
200 |
</PRE>
|
|
|
201 |
This defines the token, <I>ptr_add</I>, to produce something of
|
|
|
202 |
<CODE>SORT</CODE> <CODE>EXP</CODE>. It has three parameters, of
|
|
|
203 |
<CODE>SORT</CODE>s <CODE>EXP</CODE>, <CODE>EXP</CODE> and
|
|
|
204 |
<CODE>SHAPE</CODE>. The <I>add_to_ptr</I>, <I>offset_mult</I>,
|
|
|
205 |
<I>offset_pad</I>, <I>alignment</I> and <I>shape_offset</I>
|
|
|
206 |
constructions are TDF constructions producing respectively an
|
|
|
207 |
<CODE>EXP</CODE>, an <CODE>EXP</CODE>, an <CODE>EXP</CODE>, an
|
|
|
208 |
<CODE>ALIGNMENT</CODE> and an <CODE>EXP</CODE>.
|
|
|
209 |
<P>
|
|
|
210 |
A typical use of this token is:
|
|
|
211 |
<PRE>
|
|
|
212 |
<I>ptr_add(
|
|
|
213 |
obtain_tag(tag41),
|
|
|
214 |
contents(integer(~signed_int), obtain_tag(tag62)),
|
|
|
215 |
integer(~char))</I>
|
|
|
216 |
</PRE>
|
|
|
217 |
The effect of this use is to produce the TDF of the definition with
|
|
|
218 |
<I>par0</I>, <I>par1</I> and <I>par2</I> substituted by the actual
|
|
|
219 |
parameters.
|
|
|
220 |
<P>
|
|
|
221 |
There is no way of obtaining anything like a side-effect. A token
|
|
|
222 |
without parameters is therefore just a constant.
|
|
|
223 |
<P>
|
|
|
224 |
Tokens can be used for various purposes. They are used to make the
|
|
|
225 |
TDF shorter by using tokens for commonly used constructions (<I>ptr_add</I>
|
|
|
226 |
is an example of this use). They are used to make target dependent
|
|
|
227 |
substitutions (<I>~char</I> in the use of <I>ptr_add</I> is an example
|
|
|
228 |
of this, since <I>~char</I> may be signed or unsigned on the target).
|
|
|
229 |
<P>
|
|
|
230 |
A particularly important use is to provide definitions appropriate
|
|
|
231 |
to the translation of a particular language. Another is to abstract
|
|
|
232 |
those features which differ from one ABI to another. This kind of
|
|
|
233 |
use requires that sets of tokens should be standardised for these
|
|
|
234 |
purposes, since otherwise there will be a proliferation of such definitions.
|
|
|
235 |
<P>
|
|
|
236 |
<A NAME=S7>
|
|
|
237 |
<H2>2.3. Tags</H2>
|
|
|
238 |
Tags are used to identify the actual program components. They can
|
|
|
239 |
be declared or defined. A declaration gives the <CODE>SHAPE</CODE>
|
|
|
240 |
of a tag (a <CODE>SHAPE</CODE> is the TDF analogue of a type). A definition
|
|
|
241 |
gives an <CODE>EXP</CODE> for the tag (an <CODE>EXP</CODE> describes
|
|
|
242 |
how the value is to be made up).
|
|
|
243 |
<P>
|
|
|
244 |
<A NAME=S8>
|
|
|
245 |
<H2>2.4. Extending the format</H2>
|
|
|
246 |
<A NAME=M12>TDF can be extended for two major reasons.
|
|
|
247 |
<P>
|
|
|
248 |
First, as part of the evolution of TDF, new features will from time
|
|
|
249 |
to time be identified. It is highly desirable that these can be added
|
|
|
250 |
without disturbing the current encoding, so that old TDF can still
|
|
|
251 |
be installed by systems which recognise the new constructions. Such
|
|
|
252 |
changes should only be made infrequently and with great care, for
|
|
|
253 |
stability reasons, but nevertheless they must be allowed for in the
|
|
|
254 |
design.
|
|
|
255 |
<P>
|
|
|
256 |
Second, it may be required to add extra information to TDF to permit
|
|
|
257 |
special processing. TDF is a way of describing programs and it clearly
|
|
|
258 |
may be used for other reasons than portability and distribution. In
|
|
|
259 |
these uses it may be necessary to add extra information which is closely
|
|
|
260 |
integrated with the program. Diagnostics and profiling can serve as
|
|
|
261 |
examples. In these cases the extra kinds of information may not have
|
|
|
262 |
been allowed for in the TDF encoding.
|
|
|
263 |
<P>
|
|
|
264 |
Some extension mechanisms are described below and related to these
|
|
|
265 |
reasons:
|
|
|
266 |
<UL>
|
|
|
267 |
<LI>The encoding of every <CODE>SORT</CODE> in TDF can be extended
|
|
|
268 |
indefinitely (except for certain auxiliary <CODE>SORT</CODE>s). This
|
|
|
269 |
mechanism should only be used for extending standard TDF to the next
|
|
|
270 |
standard, since otherwise extensions made by different groups of people
|
|
|
271 |
might conflict with each other. See <A HREF="spec11.html#13">Extendable
|
|
|
272 |
integer encoding</A>.<P>
|
|
|
273 |
<LI>Basic TDF has three kinds of linkable entity and seven kinds of
|
|
|
274 |
unit. It also contains a mechanism for extending these so that other
|
|
|
275 |
information can be transmitted in a capsule and properly related to
|
|
|
276 |
basic TDF. The rules for linking this extra information are also laid
|
|
|
277 |
down. See <A HREF="spec8.html#M53">make_capsule</A>.
|
|
|
278 |
<P>
|
|
|
279 |
If a new kind of unit is added, it can contain any information, but
|
|
|
280 |
if it is to refer to the tags and tokens of other units it must use
|
|
|
281 |
the linkable entities. Since new kinds of unit might need extra kinds
|
|
|
282 |
of linkable entity, a method for adding these is also provided. All
|
|
|
283 |
this works in a uniform way, with capsule level tables of the new
|
|
|
284 |
entities, and external and internal links for them.
|
|
|
285 |
<P>
|
|
|
286 |
If new kinds of unit are added, the order of groups must be the same
|
|
|
287 |
in any capsules which are linked together. As an example of the use
|
|
|
288 |
of this kind of extension, the diagnostic information is introduced
|
|
|
289 |
in just this way. It uses two extra kinds of unit and one extra kind
|
|
|
290 |
of linkable entity. The extra units need to refer to the tags in the
|
|
|
291 |
other units, since these are the object of the diagnostic information.
|
|
|
292 |
This mechanism can be used for both purposes.<P>
|
|
|
293 |
<LI>The parameters of tokens are encoded in such a way that foreign
|
|
|
294 |
information (that is, information which cannot be expressed in the
|
|
|
295 |
TDF <CODE>SORT</CODE>s) can be supplied. This mechanism should only
|
|
|
296 |
be used for the second purpose, though it could be used to experiment
|
|
|
297 |
with extensions for future standards. See
|
|
|
298 |
<A HREF="spec11.html#8"><CODE>BITSTREAM</CODE></A>.
|
|
|
299 |
</UL>
|
|
|
300 |
<P>
|
|
|
301 |
<HR>
|
|
|
302 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
303 |
Copyright © 1998.</I></P>
|
|
|
304 |
</BODY>
|
|
|
305 |
</HTML>
|