| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>TDF Token Register</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
|
|
|
8 |
<H1>TDF Token Register</H1>
|
|
|
9 |
<H3>January 1998</H3>
|
|
|
10 |
<IMG SRC="../images/no_next.gif" ALT="next section">
|
|
|
11 |
<IMG SRC="../images/no_prev.gif" ALT="previous section">
|
|
|
12 |
<IMG SRC="../images/no_top.gif" ALT="current document">
|
|
|
13 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
14 |
</A>
|
|
|
15 |
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
|
|
|
16 |
<HR>
|
|
|
17 |
<DL>
|
|
|
18 |
<DT><A HREF="#S2"><B>1</B> - Introduction</A><DD>
|
|
|
19 |
<DL>
|
|
|
20 |
<DT><A HREF="#S3"><B>1.1</B> - Background</A><DD>
|
|
|
21 |
<DT><A HREF="#S4"><B>1.2</B> - Token Register Objectives</A><DD>
|
|
|
22 |
</DL>
|
|
|
23 |
<DT><A HREF="#S5"><B>2</B> - Naming scheme</A><DD>
|
|
|
24 |
<DT><A HREF="#S6"><B>3</B> - Target dependency tokens</A><DD>
|
|
|
25 |
<DL>
|
|
|
26 |
<DT><A HREF="#S7"><B>3.1</B> - Integer variety representations</A><DD>
|
|
|
27 |
<DT><A HREF="#S8"><B>3.2</B> - Floating variety representations</A><DD>
|
|
|
28 |
<DT><A HREF="#S9"><B>3.3</B> - Non-numeric representations</A><DD>
|
|
|
29 |
<DT><A HREF="#S10"><B>3.4</B> - Common conversion routines</A><DD>
|
|
|
30 |
</DL>
|
|
|
31 |
<DT><A HREF="#S11"><B>4</B> - Basic mapping tokens</A><DD>
|
|
|
32 |
<DL>
|
|
|
33 |
<DT><A HREF="#S12"><B>4.1</B> - C mapping tokens</A><DD>
|
|
|
34 |
<DT><A HREF="#S13"><B>4.2</B> - Fortran mapping tokens</A><DD>
|
|
|
35 |
</DL>
|
|
|
36 |
<DT><A HREF="#S14"><B>5</B> - TDF Interface tokens</A><DD>
|
|
|
37 |
<DL>
|
|
|
38 |
<DT><A HREF="#S15"><B>5.1</B> - Exception handling</A><DD>
|
|
|
39 |
<DT><A HREF="#S16"><B>5.2</B> - TDF Diagnostic Specification</A><DD>
|
|
|
40 |
<DT><A HREF="#S17"><B>5.3</B> - Accessing variable parameter lists</A><DD>
|
|
|
41 |
</DL>
|
|
|
42 |
<DT><A HREF="#S18"><B>6</B> - Language Programming Interfaces</A><DD>
|
|
|
43 |
<DL>
|
|
|
44 |
<DT><A HREF="#S19"><B>6.1</B> - The DRA C LPI</A><DD>
|
|
|
45 |
<DT><A HREF="#S191"><B>6.2</B> - The DRA C++ LPI</A><DD>
|
|
|
46 |
<DT><A HREF="#S20"><B>6.3</B> - The Etnoteam Fortran LPI</A><DD>
|
|
|
47 |
</DL>
|
|
|
48 |
<DT><A HREF="#S21"><B>7</B> - Application Programming Interfaces</A><DD>
|
|
|
49 |
<DL>
|
|
|
50 |
<DT><A HREF="#S22"><B>7.1</B> - ANSI C standard functions</A><DD>
|
|
|
51 |
<DT><A HREF="#S23"><B>7.2</B> - Common exceptional cases</A><DD>
|
|
|
52 |
</DL>
|
|
|
53 |
</DL>
|
|
|
54 |
|
|
|
55 |
<HR>
|
|
|
56 |
<H2><A NAME=S2>1. Introduction</A></H2>
|
|
|
57 |
<H3><A NAME=S3>1.1. Background</A></H3>
|
|
|
58 |
TDF is an interface used for architecture neutral and programming
|
|
|
59 |
language neutral representation of program. It is used both within
|
|
|
60 |
portable language specific compilation systems, and for architecture
|
|
|
61 |
neutral distribution of compiled programs. For full details see
|
|
|
62 |
<A HREF="spec1.html">TDF Specification, Issue 4.0 (Revision 1)</A>.
|
|
|
63 |
<P>
|
|
|
64 |
TDF tokens offer a general encapsulation and expansion mechanism which
|
|
|
65 |
allows any implementation detail to be delayed to the most appropriate
|
|
|
66 |
stage of program translation. This provides a means for encapsulating
|
|
|
67 |
any target dependencies in a neutral form, with specific implementations
|
|
|
68 |
defined through standard TDF features. This raises a natural opportunity
|
|
|
69 |
for well understood sets of TDF tokens to be included along with TDF
|
|
|
70 |
itself as interface between TDF tools.
|
|
|
71 |
<P>
|
|
|
72 |
This first revision includes additional tokens for accessing variable
|
|
|
73 |
parameter lists (see <A HREF="#S17">section 5.3</A>), and a C mapping
|
|
|
74 |
token to support the optional type <I>long long int</I>.
|
|
|
75 |
<P>
|
|
|
76 |
<H3><A NAME=S4>1.2. Token Register Objectives</A></H3>
|
|
|
77 |
As TDF tokens may be used to represent any piece of TDF, they may
|
|
|
78 |
be used to supplement any TDF interface between software tools. However,
|
|
|
79 |
that raises the issue of control authority for such an interface.
|
|
|
80 |
In many cases, the interfaces may be considered to `belong' to a particular
|
|
|
81 |
tool. In other cases, the names and specifications of tokens need
|
|
|
82 |
to be recorded for common use.
|
|
|
83 |
<P>
|
|
|
84 |
This token register is used to record the names and specifications
|
|
|
85 |
of tokens which may need to be assumed by more than one software tool.
|
|
|
86 |
It also defines a naming scheme which should be used consistently
|
|
|
87 |
to avoid ambiguity between tokens.
|
|
|
88 |
<P>
|
|
|
89 |
Five classes of tokens are identified:
|
|
|
90 |
<P>
|
|
|
91 |
<OL>
|
|
|
92 |
<LI>target dependency tokens, which are concerned with describing
|
|
|
93 |
target architecture or translator detail;
|
|
|
94 |
<P>
|
|
|
95 |
<LI>basic mapping tokens, which relate general language features to
|
|
|
96 |
architecture detail;
|
|
|
97 |
<P>
|
|
|
98 |
<LI>TDF interface tokens, which may be required to complete the specification
|
|
|
99 |
of some TDF constructs;
|
|
|
100 |
<P>
|
|
|
101 |
<LI>language programming interfaces (LPI) which may be specific to
|
|
|
102 |
a particular producer;
|
|
|
103 |
<P>
|
|
|
104 |
<LI>application programming interfaces (API).
|
|
|
105 |
</OL>
|
|
|
106 |
These classes are discussed separately, in sections <A HREF="#S6">3</A>
|
|
|
107 |
to <A HREF="#S21">7</A> below.
|
|
|
108 |
<P>
|
|
|
109 |
|
|
|
110 |
<HR>
|
|
|
111 |
<H2><A NAME=S5>2. Naming scheme</A></H2>
|
|
|
112 |
A flat name space will suffice for TDF token names if producer writers
|
|
|
113 |
adopt the simple constraints described here. TDF has separate provision
|
|
|
114 |
for a hierarchic unique naming scheme, but that was intended for a
|
|
|
115 |
specific purpose that has not yet been realised.
|
|
|
116 |
<P>
|
|
|
117 |
External names for program or application specific tokens should be
|
|
|
118 |
confined to `simple names', which we define to mean that they consist
|
|
|
119 |
only of letters, digits and underscore, the characters allowed in
|
|
|
120 |
C identifiers. Normally there will be very few such external names,
|
|
|
121 |
as tokens internal to a single capsule do not require to be named.
|
|
|
122 |
All other token names will consist of some controlled prefix followed
|
|
|
123 |
by a simple name, with the prefix identifying the control authority.
|
|
|
124 |
<P>
|
|
|
125 |
For API tokens, the prefix will consist of a sequence of simple names,
|
|
|
126 |
each followed by a dot, where the first simple name is the name of
|
|
|
127 |
the API as listed or referred to in section <A HREF="#S21">7</A>.
|
|
|
128 |
<P>
|
|
|
129 |
The prefix for producer specific and target dependency tokens will
|
|
|
130 |
begin and end with characters that distinguish them from the above
|
|
|
131 |
cases. However, common tools such as DISP, TNC and PL-TDF assume that
|
|
|
132 |
token names contain only letters, digits, underscore, dot, and/or
|
|
|
133 |
twiddle.
|
|
|
134 |
<P>
|
|
|
135 |
The following prefixes are currently reserved:
|
|
|
136 |
<P>
|
|
|
137 |
<DL>
|
|
|
138 |
<DT><CODE>~</CODE><DD>TDF interface tokens as specified in section
|
|
|
139 |
<A HREF="#S14">5</A> below, and also LPI tokens specific to DRA's
|
|
|
140 |
C producer.
|
|
|
141 |
<DT><CODE>.~</CODE><DD>Registered target dependency tokens as specified
|
|
|
142 |
in section <A HREF="#S6">3</A> below, and basic mapping tokens specified
|
|
|
143 |
in section <A HREF="#S11">4</A>.
|
|
|
144 |
<DT><CODE>~cpp.</CODE><DD>LPI tokens specific to DRA's C++ producer,
|
|
|
145 |
other than those it shares with the C producer.
|
|
|
146 |
<DT>.Et~<DD>LPI tokens specific to Etnoteam's Fortran77 producer.
|
|
|
147 |
</DL>
|
|
|
148 |
|
|
|
149 |
<P>
|
|
|
150 |
|
|
|
151 |
<HR>
|
|
|
152 |
<H2><A NAME=S6>3. Target dependency tokens</A></H2>
|
|
|
153 |
Target dependency tokens provide a common interface to simple constructs
|
|
|
154 |
where the required detail for any specific architecture can be expressed
|
|
|
155 |
within TDF, but the detail will be architecture specific. Every installer
|
|
|
156 |
should have associated with it, a capsule containing the installer
|
|
|
157 |
specific definitions of all the tokens specificed within this section
|
|
|
158 |
<A HREF="#S6">3</A>.
|
|
|
159 |
<P>
|
|
|
160 |
Some of these tokens provide information about the integer and floating
|
|
|
161 |
point variety representations supported by an installer, in a form
|
|
|
162 |
that may be used by TDF analysis tools for architecture specific analysis,
|
|
|
163 |
or by library generation tools when generating an architecture specific
|
|
|
164 |
version of a library. Other target dependency tokens provide commonly
|
|
|
165 |
required conversion routines.
|
|
|
166 |
<P>
|
|
|
167 |
It is recommended that these tokens should not be used directly within
|
|
|
168 |
application programs. They are designed for use within LPI definitions,
|
|
|
169 |
which can provide a more appropriate interface for applications.
|
|
|
170 |
<P>
|
|
|
171 |
<H3><A NAME=S7>3.1. Integer variety representations</A></H3>
|
|
|
172 |
Since TDF specifies integer representations to be twos-complement,
|
|
|
173 |
the number of bits required to store an integer variety representation
|
|
|
174 |
fully specifies that representation. The minimum or maximum signed
|
|
|
175 |
or unsigned integer that can be represented within any variety representation
|
|
|
176 |
can easily be determined from the number of bits.
|
|
|
177 |
<P>
|
|
|
178 |
<B>3.1.1.</B> <CODE>.~rep_var_width</CODE>
|
|
|
179 |
<P>
|
|
|
180 |
<PRE>
|
|
|
181 |
<I>w</I>: NAT
|
|
|
182 |
-> NAT
|
|
|
183 |
</PRE>
|
|
|
184 |
If <I>w </I>lies within the range of <CODE>VARIETY</CODE> sizes supported
|
|
|
185 |
by the associated installer, <I>rep_var_width</I>(<I>w</I>) will be
|
|
|
186 |
the number of bits required to store values of <CODE>VARIETY</CODE>
|
|
|
187 |
<I>var_width</I>(
|
|
|
188 |
<I>b</I>,<I>w</I>), for any <CODE>BOOL</CODE> <I>b</I>.
|
|
|
189 |
<P>
|
|
|
190 |
If <I>w </I>is outside the range of <CODE>VARIETY</CODE> sizes supported
|
|
|
191 |
by the associated installer, <I>rep_var_width</I>(<I>w</I>) will be
|
|
|
192 |
0.
|
|
|
193 |
<P>
|
|
|
194 |
<B>3.1.2.</B> <CODE>.~rep_atomic_width</CODE>
|
|
|
195 |
<P>
|
|
|
196 |
<PRE>
|
|
|
197 |
-> NAT
|
|
|
198 |
</PRE>
|
|
|
199 |
<I>.~rep_atomic_width</I> will be the number of bits required to store
|
|
|
200 |
values of some <CODE>VARIETY</CODE> <I>v </I>such that <I>assign</I>
|
|
|
201 |
and <I>assign_with_mode</I> are atomic operations if the value assigned
|
|
|
202 |
has <CODE>SHAPE</CODE> <I>integer</I>(<I>v</I>). The TDF specification
|
|
|
203 |
guarantees existence of such a number.
|
|
|
204 |
<P>
|
|
|
205 |
<H3><A NAME=S8>3.2. Floating variety representations</A></H3>
|
|
|
206 |
Floating point representations are much more diverse than integers,
|
|
|
207 |
but we may assume that each installer will support a finite set of
|
|
|
208 |
distinct representations. For convenience in distinguishing between
|
|
|
209 |
these representations within architecture specific TDF, the set of
|
|
|
210 |
distinct representations supported by any specific installer are stated
|
|
|
211 |
to be ordered into a sequence of non-decreasing memory size. An analysis
|
|
|
212 |
tool can easily count through this sequence to determine the properties
|
|
|
213 |
of all supported representations, starting at 1 and using <I>.~rep_fv_width
|
|
|
214 |
</I> to test for the sequence end.
|
|
|
215 |
<P>
|
|
|
216 |
<B>3.2.1.</B> <CODE>.~rep_fv</CODE>
|
|
|
217 |
<P>
|
|
|
218 |
<PRE>
|
|
|
219 |
<I>n</I>: NAT
|
|
|
220 |
-> FLOATING_VARIETY
|
|
|
221 |
</PRE>
|
|
|
222 |
<I>.~rep_fv</I>(<I>n</I>) will be the <CODE>FLOATING_VARIETY</CODE>
|
|
|
223 |
whose representation is the <I>n</I>th of the sequence of supported
|
|
|
224 |
floating point representations.
|
|
|
225 |
<I>n</I> will lie within this range.
|
|
|
226 |
<P>
|
|
|
227 |
<B>3.2.2.</B> <CODE>.~rep_fv_width</CODE>
|
|
|
228 |
<P>
|
|
|
229 |
<PRE>
|
|
|
230 |
<I>n</I>: NAT
|
|
|
231 |
-> NAT
|
|
|
232 |
</PRE>
|
|
|
233 |
If <I>n</I> lies within the sequence range of supported floating point
|
|
|
234 |
representations, <I>.~rep_fv_width</I>(<I>n</I>) will be the number
|
|
|
235 |
of bits required to store values of <CODE>FLOATING_VARIETY</CODE>
|
|
|
236 |
<I>.~rep_fv</I>(<I>n</I>).
|
|
|
237 |
<P>
|
|
|
238 |
If <I>n</I> is outside the sequence range of supported floating point
|
|
|
239 |
representations, <I>.~rep_fv_width</I>(<I>n</I>) will be 0.
|
|
|
240 |
<P>
|
|
|
241 |
<B>3.2.3.</B> <CODE>.~rep_fv_radix</CODE>
|
|
|
242 |
<P>
|
|
|
243 |
<PRE>
|
|
|
244 |
<I>n</I>: NAT
|
|
|
245 |
-> NAT
|
|
|
246 |
</PRE>
|
|
|
247 |
<I>.~rep_fv_radix</I>(<I>n</I>) will be the radix used in the representation
|
|
|
248 |
of values of <CODE>FLOATING_VARIETY</CODE> <I>.~rep_fv</I>(<I>n</I>).
|
|
|
249 |
|
|
|
250 |
<P>
|
|
|
251 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
252 |
point representations.
|
|
|
253 |
<P>
|
|
|
254 |
<B>3.2.4.</B> <CODE>.~rep_fv_mantissa</CODE>
|
|
|
255 |
<P>
|
|
|
256 |
<PRE>
|
|
|
257 |
<I>n</I>: NAT
|
|
|
258 |
-> NAT
|
|
|
259 |
</PRE>
|
|
|
260 |
<I>.~rep_fv_mantissa</I>(<I>n</I>) will be the number of base
|
|
|
261 |
<I>.~rep_fv_radix</I>(<I>n</I>) digits in the mantissa representation
|
|
|
262 |
of values of <CODE>FLOATING_VARIETY</CODE> <I>.~rep_fv</I>(<I>n</I>).
|
|
|
263 |
|
|
|
264 |
<P>
|
|
|
265 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
266 |
point representations.
|
|
|
267 |
<P>
|
|
|
268 |
<B>3.2.5.</B> <CODE>.~rep_fv_min_exp</CODE>
|
|
|
269 |
<P>
|
|
|
270 |
<PRE>
|
|
|
271 |
<I>n</I>: NAT
|
|
|
272 |
-> NAT
|
|
|
273 |
</PRE>
|
|
|
274 |
<I>.~rep_fv_min_exp</I>(<I>n</I>) will be the maximum integer
|
|
|
275 |
<I>m</I> such that (<I>.~rep_fv_radix</I>(<I>n</I>))<I>-m</I>
|
|
|
276 |
is exactly representable (though not necessarily normalised) by the
|
|
|
277 |
<CODE>FLOATING_VARIETY</CODE> <I>.~rep_fv</I>(<I>n</I>).
|
|
|
278 |
<P>
|
|
|
279 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
280 |
point representations.
|
|
|
281 |
<P>
|
|
|
282 |
<B>3.2.6.</B> <CODE>.~rep_fv_max_exp</CODE>
|
|
|
283 |
<P>
|
|
|
284 |
<PRE>
|
|
|
285 |
<I>n</I>: NAT
|
|
|
286 |
-> NAT
|
|
|
287 |
</PRE>
|
|
|
288 |
<I>.~rep_fv_max_exp</I>(<I>n</I>) will be the maximum integer
|
|
|
289 |
<I>m</I> such that (<I>.~rep_fv_radix</I>(<I>n</I>))<I>m</I>
|
|
|
290 |
is exactly representable by the <CODE>FLOATING_VARIETY</CODE> <I>.~rep_fv</I>(
|
|
|
291 |
<I>n</I>).
|
|
|
292 |
<P>
|
|
|
293 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
294 |
point representations.
|
|
|
295 |
<P>
|
|
|
296 |
<B>3.2.7.</B> <CODE>.~rep_fv_epsilon</CODE>
|
|
|
297 |
<P>
|
|
|
298 |
<PRE>
|
|
|
299 |
<I>n</I>: NAT
|
|
|
300 |
-> EXP FLOATING .~rep_fv(<I>n</I>)
|
|
|
301 |
</PRE>
|
|
|
302 |
<I>.~rep_fv_epsilon</I>(<I>n</I>) will be the smallest strictly positive
|
|
|
303 |
real <I>x </I>such that (1.0 + <I>x</I>) is exactly representable
|
|
|
304 |
by the <CODE>FLOATING_VARIETY</CODE> <I>.~rep_fv(n)</I>.
|
|
|
305 |
<P>
|
|
|
306 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
307 |
point representations.
|
|
|
308 |
<P>
|
|
|
309 |
<B>3.2.8.</B> <CODE>.~rep_fv_min_val</CODE>
|
|
|
310 |
<P>
|
|
|
311 |
<PRE>
|
|
|
312 |
<I>n</I>: NAT
|
|
|
313 |
-> EXP FLOATING .~rep_fv(<I>n</I>)
|
|
|
314 |
</PRE>
|
|
|
315 |
<I>.~rep_fv_min_val</I>(<I>n</I>) will be the smallest strictly positive
|
|
|
316 |
real number that is exactly representable (though not necessarily
|
|
|
317 |
normalised)) by the <CODE>FLOATING_VARIETY</CODE> <I>.~rep_fv(n)</I>.
|
|
|
318 |
<P>
|
|
|
319 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
320 |
point representations.
|
|
|
321 |
<P>
|
|
|
322 |
<B>3.2.9.</B> <CODE>.~rep_fv_max_val</CODE>
|
|
|
323 |
<P>
|
|
|
324 |
<PRE>
|
|
|
325 |
<I>n</I>: NAT
|
|
|
326 |
-> EXP FLOATING .~rep_fv(<I>n</I>)
|
|
|
327 |
</PRE>
|
|
|
328 |
<I>.~rep_fv_max_val</I>(<I>n</I>) will be the largest real number
|
|
|
329 |
that is exactly representable by the <CODE>FLOATING_VARIETY</CODE>
|
|
|
330 |
<I>.~rep_fv(n)</I>.
|
|
|
331 |
<P>
|
|
|
332 |
<I>n</I> will lie within the sequence range of supported floating
|
|
|
333 |
point representations.
|
|
|
334 |
<P>
|
|
|
335 |
<H3><A NAME=S9>3.3. Non-numeric representations</A></H3>
|
|
|
336 |
<B>3.3.1.</B> <CODE>.~ptr_width</CODE>
|
|
|
337 |
<P>
|
|
|
338 |
<PRE>
|
|
|
339 |
-> NAT
|
|
|
340 |
</PRE>
|
|
|
341 |
<I>.~ptr_width</I> will be the minimum <I>.~rep_var_width</I>(<I>w</I>)
|
|
|
342 |
for any <I>w </I>such that any pointer to any alignment may be converted
|
|
|
343 |
to an integer of <CODE>VARIETY</CODE> <I>var_width</I>(<I>b</I>,<I>w</I>),
|
|
|
344 |
for some <CODE>BOOL</CODE> <I>b</I>, and back again without loss of
|
|
|
345 |
information, using the conversions <I>.~ptr_to_int</I> and <I>.~int_to_ptr</I>
|
|
|
346 |
(q.v.).
|
|
|
347 |
<P>
|
|
|
348 |
<B>3.3.2.</B> <CODE>.~best_div</CODE>
|
|
|
349 |
<P>
|
|
|
350 |
<PRE>
|
|
|
351 |
-> NAT
|
|
|
352 |
</PRE>
|
|
|
353 |
<I>.~best_div</I> is 1 or 2 to indicate preference for class 1 or
|
|
|
354 |
class 2 division and modulus (as defined in the TDF Specification).
|
|
|
355 |
This token would be used in situations where either class is valid
|
|
|
356 |
but must be used consistently.
|
|
|
357 |
<P>
|
|
|
358 |
<B>3.3.3.</B> <CODE>.~little_endian</CODE>
|
|
|
359 |
<P>
|
|
|
360 |
<PRE>
|
|
|
361 |
-> BOOL
|
|
|
362 |
</PRE>
|
|
|
363 |
<I>.~little_endian</I> is a property of the relationship between different
|
|
|
364 |
variety representations and arrays. If an array of a smaller variety
|
|
|
365 |
can be mapped onto a larger variety, and <I>.~little_endian</I>
|
|
|
366 |
is true, then smaller indices of the smaller variety array map onto
|
|
|
367 |
smaller ranges of the larger variety. If <I>.~little_endian</I>
|
|
|
368 |
is false, no such assertion can be made.
|
|
|
369 |
<P>
|
|
|
370 |
<H3><A NAME=S10>3.4. Common conversion routines</A></H3>
|
|
|
371 |
This subsection contains a set of conversion routines between values
|
|
|
372 |
of different shapes, that are not required to have any specific meaning
|
|
|
373 |
apart from reversability. If the storage space requirements for the
|
|
|
374 |
two shapes are identical, the conversion can usually be achieved without
|
|
|
375 |
change of representation. When that is the case, and if the two shapes
|
|
|
376 |
can be stored at a common alignment, the conversion can simply be
|
|
|
377 |
achieved by assignment via a common union, which will ensure the required
|
|
|
378 |
alignment consistency.
|
|
|
379 |
<P>
|
|
|
380 |
<B>3.4.1.</B> <CODE>.~ptr_to_ptr</CODE>
|
|
|
381 |
<P>
|
|
|
382 |
<PRE>
|
|
|
383 |
<I>a1</I>: ALIGNMENT
|
|
|
384 |
<I>a2</I>: ALIGNMENT
|
|
|
385 |
<I>p</I>: EXP POINTER(<I>a1</I>)
|
|
|
386 |
-> EXP POINTER(<I>a2</I>)
|
|
|
387 |
</PRE>
|
|
|
388 |
<I>.~ptr_to_ptr</I> converts pointers from one pointer shape to another.
|
|
|
389 |
|
|
|
390 |
<P>
|
|
|
391 |
If <I>p</I> is any pointer with alignment <I>a1</I>, then <I>.~ptr_to_ptr
|
|
|
392 |
</I>(<I>a2</I>, <I>a1</I>, <I>.~ptr_to_ptr</I>(<I>a1</I>,
|
|
|
393 |
<I>a2</I>, <I>p</I>)) shall result in the same pointer <I>p</I>, provided
|
|
|
394 |
that the number of bits required to store a pointer with alignment
|
|
|
395 |
<I>a2</I> is not less than that required to store a pointer with alignment
|
|
|
396 |
<I>a1</I>.
|
|
|
397 |
<P>
|
|
|
398 |
<B>3.4.2.</B> <CODE>.~ptr_to_int</CODE>
|
|
|
399 |
<P>
|
|
|
400 |
<PRE>
|
|
|
401 |
<I>a</I>: ALIGNMENT
|
|
|
402 |
<I>v</I>: VARIETY
|
|
|
403 |
<I>p</I>: EXP POINTER(<I>a</I>)
|
|
|
404 |
-> EXP INTEGER(<I>v</I>)
|
|
|
405 |
</PRE>
|
|
|
406 |
<I>.~ptr_to_int</I> converts a pointer to an integer. The result is
|
|
|
407 |
undefined if the <CODE>VARIETY</CODE> v is insufficient to distinguish
|
|
|
408 |
between all possible distinct pointers <I>p</I> of alignment <I>a</I>.
|
|
|
409 |
<P>
|
|
|
410 |
<B>3.4.3.</B> <CODE>.~int_to_ptr</CODE>
|
|
|
411 |
<P>
|
|
|
412 |
<PRE>
|
|
|
413 |
<I>v</I>: VARIETY
|
|
|
414 |
<I>a</I>: ALIGNMENT
|
|
|
415 |
<I>i</I>: EXP INTEGER(<I>v</I>)
|
|
|
416 |
-> EXP POINTER(<I>a</I>)
|
|
|
417 |
</PRE>
|
|
|
418 |
<I>.~int_to_ptr</I> converts an integer to a pointer. The result is
|
|
|
419 |
undefined unless the integer i was obtained without modification from
|
|
|
420 |
some pointer using <I>.~ptr_to_int</I> with the same variety and alignment
|
|
|
421 |
arguments.
|
|
|
422 |
<P>
|
|
|
423 |
If <I>p</I> is any pointer with alignment <I>a</I>, and <I>v</I>
|
|
|
424 |
is <I>var_width</I>(<I>b</I>, <I>.~ptr_width</I>) for some <CODE>BOOL</CODE>
|
|
|
425 |
<I>b</I>, then <I>.~int_to_ptr</I>(<I>v</I>, <I>a</I>, <I>.~ptr_to_int
|
|
|
426 |
</I>(<I>a</I>, <I>v</I>, <I>p</I>)) shall result in the same pointer
|
|
|
427 |
<I>p</I>.
|
|
|
428 |
<P>
|
|
|
429 |
<B>3.4.4.</B> <CODE>.~f_to_ptr</CODE>
|
|
|
430 |
<P>
|
|
|
431 |
<PRE>
|
|
|
432 |
<I>a</I>: ALIGNMENT
|
|
|
433 |
<I>fn</I>: EXP PROC
|
|
|
434 |
-> EXP POINTER(<I>a</I>)
|
|
|
435 |
</PRE>
|
|
|
436 |
<I>.~f_to_ptr</I> converts a procedure to a pointer. The result is
|
|
|
437 |
undefined except as required for consistency with <I>.~ptr_to_f</I>.
|
|
|
438 |
<P>
|
|
|
439 |
<B>3.4.5.</B> <CODE>.~ptr_to_f</CODE>
|
|
|
440 |
<P>
|
|
|
441 |
<PRE>
|
|
|
442 |
<I>a</I>: ALIGNMENT
|
|
|
443 |
<I>p</I>: EXP POINTER(<I>a</I>)
|
|
|
444 |
-> EXP PROC
|
|
|
445 |
</PRE>
|
|
|
446 |
<I>.~ptr_to_f</I> converts a pointer to a procedure. The result is
|
|
|
447 |
undefined unless the pointer p was obtained without modification from
|
|
|
448 |
some procedure <I>f</I> using <I>.~f_to_ptr</I>(<I>a</I>,
|
|
|
449 |
<I>f</I>). The same procedure <I>f</I> is delivered.
|
|
|
450 |
<P>
|
|
|
451 |
|
|
|
452 |
<HR>
|
|
|
453 |
<H2><A NAME=S11>4. Basic mapping tokens</A></H2>
|
|
|
454 |
Basic mapping tokens provide target specific detail for specific language
|
|
|
455 |
features that are defined to be target dependent. This detail need
|
|
|
456 |
not be fixed for a particular target architecture, but needs to provide
|
|
|
457 |
compatibility with any external library with which an application
|
|
|
458 |
program is to be linked.
|
|
|
459 |
<P>
|
|
|
460 |
Tokens specific to the C and Fortran language families are included.
|
|
|
461 |
Like the target dependency tokens, it is again recommended that these
|
|
|
462 |
tokens should not be used directly within application programs. They
|
|
|
463 |
are designed for use within LPI definitions, which can provide a more
|
|
|
464 |
appropriate interface for applications.
|
|
|
465 |
<P>
|
|
|
466 |
Every operating system variant of an installer should have associated
|
|
|
467 |
with it, a capsule containing the definitions of all the tokens specificed
|
|
|
468 |
within this section <A HREF="#S11">4</A>.
|
|
|
469 |
<P>
|
|
|
470 |
<H3><A NAME=S12>4.1. C mapping tokens</A></H3>
|
|
|
471 |
<B>4.1.1.</B> <CODE>.~char_width</CODE>
|
|
|
472 |
<P>
|
|
|
473 |
<PRE>
|
|
|
474 |
-> NAT
|
|
|
475 |
</PRE>
|
|
|
476 |
<I>.~char_width</I> is the number of bits required to store values
|
|
|
477 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
478 |
C type <I>char</I>.
|
|
|
479 |
<P>
|
|
|
480 |
<B>4.1.2.</B> <CODE>.~short_width</CODE>
|
|
|
481 |
<P>
|
|
|
482 |
<PRE>
|
|
|
483 |
-> NAT
|
|
|
484 |
</PRE>
|
|
|
485 |
<I>.~short_width</I> is the number of bits required to store values
|
|
|
486 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
487 |
C type <I>short int</I>.
|
|
|
488 |
<P>
|
|
|
489 |
<B>4.1.3.</B> <CODE>.~int_width</CODE>
|
|
|
490 |
<P>
|
|
|
491 |
<PRE>
|
|
|
492 |
-> NAT
|
|
|
493 |
</PRE>
|
|
|
494 |
<I>.~int_width</I> is the number of bits required to store values
|
|
|
495 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
496 |
C type <I>int</I>.
|
|
|
497 |
<P>
|
|
|
498 |
<B>4.1.4.</B> <CODE>.~long_width</CODE>
|
|
|
499 |
<P>
|
|
|
500 |
<PRE>
|
|
|
501 |
-> NAT
|
|
|
502 |
</PRE>
|
|
|
503 |
<I>.~long_width</I> is the number of bits required to store values
|
|
|
504 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
505 |
C type <I>long int</I>.
|
|
|
506 |
<P>
|
|
|
507 |
<B>4.1.5.</B> <CODE>.~longlong_width</CODE>
|
|
|
508 |
<P>
|
|
|
509 |
<PRE>
|
|
|
510 |
-> NAT
|
|
|
511 |
</PRE>
|
|
|
512 |
<I>.~longlong_width</I> is the number of bits required to store values
|
|
|
513 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
514 |
C type <I>long long int</I>.
|
|
|
515 |
<P>
|
|
|
516 |
<B>4.1.6.</B> <CODE>.~size_t_width</CODE>
|
|
|
517 |
<P>
|
|
|
518 |
<PRE>
|
|
|
519 |
-> NAT
|
|
|
520 |
</PRE>
|
|
|
521 |
<I>.~size_t_width</I> is the number of bits required to store values
|
|
|
522 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
523 |
C type <I>size_t</I>. It will be the same as one of <I>.~short_width</I>,
|
|
|
524 |
<I>.~int_width</I>, or <I>.~long_width</I>.
|
|
|
525 |
<P>
|
|
|
526 |
<B>4.1.7.</B> <CODE>.~fl_rep</CODE>
|
|
|
527 |
<P>
|
|
|
528 |
<PRE>
|
|
|
529 |
-> NAT
|
|
|
530 |
</PRE>
|
|
|
531 |
<I>.~fl_rep</I> is the sequence number (see subsection <A HREF="#S8">3.2</A>)
|
|
|
532 |
of the floating point representation to be used for values of C type
|
|
|
533 |
<I>float</I>.
|
|
|
534 |
<P>
|
|
|
535 |
<B>4.1.8.</B> <CODE>.~dbl_rep</CODE>
|
|
|
536 |
<P>
|
|
|
537 |
<PRE>
|
|
|
538 |
-> NAT
|
|
|
539 |
</PRE>
|
|
|
540 |
<I>.~dbl_rep</I> is the sequence number (see subsection 3.2) of the
|
|
|
541 |
floating point representation to be used for values of C type
|
|
|
542 |
<I>double</I>.
|
|
|
543 |
<P>
|
|
|
544 |
<B>4.1.9.</B> <CODE>.~ldbl_rep</CODE>
|
|
|
545 |
<P>
|
|
|
546 |
<PRE>
|
|
|
547 |
-> NAT
|
|
|
548 |
</PRE>
|
|
|
549 |
<I>.~ldbl_rep</I> is the sequence number (see subsection 3.2) of the
|
|
|
550 |
floating point representation to be used for values of C type
|
|
|
551 |
<I>long double</I>.
|
|
|
552 |
<P>
|
|
|
553 |
<B>4.1.10.</B> <CODE>.~pv_align</CODE>
|
|
|
554 |
<P>
|
|
|
555 |
<PRE>
|
|
|
556 |
-> ALIGNMENT
|
|
|
557 |
</PRE>
|
|
|
558 |
<I>.~pv_align</I> is the common alignment for all pointers that can
|
|
|
559 |
be represented by the C generic pointer type <I>void*</I>. For architecture
|
|
|
560 |
independence, this would have to be a union of several alignments,
|
|
|
561 |
but for many installers it can be simplified to
|
|
|
562 |
<I>alignment</I>(<I>integer</I>(<I>var_width</I>(<I>false</I>,
|
|
|
563 |
<I>.~char_width</I>))).
|
|
|
564 |
<P>
|
|
|
565 |
<B>4.1.11.</B> <CODE>.~min_struct_rep</CODE>
|
|
|
566 |
<P>
|
|
|
567 |
<PRE>
|
|
|
568 |
-> NAT
|
|
|
569 |
</PRE>
|
|
|
570 |
<I>.~min_struct_rep</I> is the number of bits required to store values
|
|
|
571 |
of the smallest C integral type which share the same alignment properties
|
|
|
572 |
as a structured value whose members are all of that same integral
|
|
|
573 |
type. It will be the same as one of <I>.~char_width</I>,
|
|
|
574 |
<I>.~short_width</I>, <I>.~int_width</I>, or <I>.~long_width</I>.
|
|
|
575 |
<P>
|
|
|
576 |
<B>4.1.12.</B> <CODE>.~char_is_signed</CODE>
|
|
|
577 |
<P>
|
|
|
578 |
<PRE>
|
|
|
579 |
-> BOOL
|
|
|
580 |
</PRE>
|
|
|
581 |
<I>.~char_is_signed</I> is <I>true</I> if the C type <I>char</I>
|
|
|
582 |
is treated as signed, or <I>false</I> if it is unsigned.
|
|
|
583 |
<P>
|
|
|
584 |
<B>4.1.13.</B> <CODE>.~bitfield_is_signed</CODE>
|
|
|
585 |
<P>
|
|
|
586 |
<PRE>
|
|
|
587 |
-> BOOL
|
|
|
588 |
</PRE>
|
|
|
589 |
<I>.~bitfield_is_signed</I> is <I>true</I> if bitfield members of
|
|
|
590 |
structures in C are treated as signed, or <I>false</I> if unsigned.
|
|
|
591 |
<P>
|
|
|
592 |
<H3><A NAME=S13>4.2. Fortran mapping tokens</A></H3>
|
|
|
593 |
<B>4.2.1.</B> <CODE>.~F_char_width</CODE>
|
|
|
594 |
<P>
|
|
|
595 |
<PRE>
|
|
|
596 |
-> NAT
|
|
|
597 |
</PRE>
|
|
|
598 |
<I>.~F_char_width</I> is the number of bits required to store values
|
|
|
599 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
600 |
Fortran77 type
|
|
|
601 |
<I>CHARACTER</I>.
|
|
|
602 |
<P>
|
|
|
603 |
In most cases, <I>.~F_char_width</I> is the same as <I>.~char_width</I>.
|
|
|
604 |
<P>
|
|
|
605 |
<B>4.2.2.</B> <CODE>.~F_int_width</CODE>
|
|
|
606 |
<P>
|
|
|
607 |
<PRE>
|
|
|
608 |
-> NAT
|
|
|
609 |
</PRE>
|
|
|
610 |
<I>.~F_int_width</I> is the number of bits required to store values
|
|
|
611 |
of the representation <CODE>VARIETY</CODE> that corresponds to the
|
|
|
612 |
Fortran77 type
|
|
|
613 |
<I>INTEGER</I>.
|
|
|
614 |
<P>
|
|
|
615 |
In most cases, <I>.~F_int_width</I> is the same as <I>.~int_width</I>.
|
|
|
616 |
<P>
|
|
|
617 |
<B>4.2.3.</B> <CODE>.~F_fl_rep</CODE>
|
|
|
618 |
<P>
|
|
|
619 |
<PRE>
|
|
|
620 |
-> NAT
|
|
|
621 |
</PRE>
|
|
|
622 |
<I>.~F_fl_rep</I> is the sequence number (see subsection <A HREF="#S8">3.2</A>)
|
|
|
623 |
of the floating point representation to be used for values of Fortran77
|
|
|
624 |
type <I>REAL</I>, with the constraint that <I>.~rep_fv_width</I>(<I>.~F_fl_rep
|
|
|
625 |
</I>) = <I>.~F_int_width</I>.
|
|
|
626 |
<P>
|
|
|
627 |
If this constraint cannot be met, <I>.~F_fl_rep</I> will be 0.
|
|
|
628 |
<P>
|
|
|
629 |
<B>4.2.4.</B> <CODE>.~F_dbl_rep</CODE>
|
|
|
630 |
<P>
|
|
|
631 |
<PRE>
|
|
|
632 |
-> NAT
|
|
|
633 |
</PRE>
|
|
|
634 |
<I>.~F_dbl_rep</I> is the sequence number (see subsection 3.2) of
|
|
|
635 |
the floating point representation to be used for values of Fortran77
|
|
|
636 |
type <I>DOUBLE PRECISION</I>, with the constraint that <I>.~rep_fv_width</I>(
|
|
|
637 |
<I>.~F_dbl_rep</I>) = 2 * <I>.~F_int_width</I>.
|
|
|
638 |
<P>
|
|
|
639 |
If this constraint cannot be met, <I>.~F_dbl_rep</I> will be 0.
|
|
|
640 |
<P>
|
|
|
641 |
|
|
|
642 |
<HR>
|
|
|
643 |
<H2><A NAME=S14>5. TDF Interface tokens</A></H2>
|
|
|
644 |
A very few specifically named tokens are referred to within the TDF
|
|
|
645 |
specification, which are required to complete the ability to use certain
|
|
|
646 |
TDF constructs. Responsibility for providing appropriate definitions
|
|
|
647 |
for these tokens is indicated with the specifications below.
|
|
|
648 |
<P>
|
|
|
649 |
Similarly, a few tokens are specified within the TDF Diagnostic Specification.
|
|
|
650 |
|
|
|
651 |
<P>
|
|
|
652 |
<H3><A NAME=S15>5.1. Exception handling</A></H3>
|
|
|
653 |
<B>5.1.1.</B> <CODE>~Throw</CODE>
|
|
|
654 |
<P>
|
|
|
655 |
<PRE>
|
|
|
656 |
<I>n</I>: NAT
|
|
|
657 |
-> EXP BOTTOM
|
|
|
658 |
</PRE>
|
|
|
659 |
The <CODE>EXP</CODE> <I>e</I> defined as the body of this token will
|
|
|
660 |
be evaluated on occurrence of any error whose <CODE>ERROR_TREATMENT</CODE>
|
|
|
661 |
is <I>trap</I>. The type of error can be determined within <I>e</I>
|
|
|
662 |
from the NAT
|
|
|
663 |
<I>n</I>, which will be <I>error_val(ec)</I> for some <CODE>ERROR_CODE</CODE>
|
|
|
664 |
<I>ec</I>. The token definition body <I>e</I> will typically consist
|
|
|
665 |
of a <I>long_jump</I> to some previously set exception handler.
|
|
|
666 |
<P>
|
|
|
667 |
Exception handling using <I>trap</I> and ~<I>Throw</I> will usually
|
|
|
668 |
be determined by producers for languages that specify their own exception
|
|
|
669 |
handling semantics. Responsibility for the <I>~Throw</I> token definition
|
|
|
670 |
will therefore normally rest with producers, by including this token
|
|
|
671 |
within the producer specific LPI.
|
|
|
672 |
<P>
|
|
|
673 |
<B>5.1.2.</B> <CODE>~Set_signal_handler</CODE>
|
|
|
674 |
<P>
|
|
|
675 |
<PRE>
|
|
|
676 |
-> EXP OFFSET (locals_alignment, locals_alignment)
|
|
|
677 |
</PRE>
|
|
|
678 |
<I>~Set_signal_handler</I> must be applied before any use of the
|
|
|
679 |
<CODE>ERROR_TREATMENT</CODE> <I>trap</I>, to indicate the need for
|
|
|
680 |
exception trapping. Responsibility for the <I>~Set_signal_handler</I>
|
|
|
681 |
token definition will rest with installers. Responsibility for applying
|
|
|
682 |
it will normally rest with producers.
|
|
|
683 |
<P>
|
|
|
684 |
The resulting offset value will contain the amount of space beyond
|
|
|
685 |
any stack limit, which must be reserved for use when handling a
|
|
|
686 |
<I>stack_overflow</I> trap raised by exceeding that limit.
|
|
|
687 |
<P>
|
|
|
688 |
<B>5.1.3.</B> <CODE>~Sync_handle</CODE>r
|
|
|
689 |
<P>
|
|
|
690 |
<PRE>
|
|
|
691 |
-> EXP TOP
|
|
|
692 |
</PRE>
|
|
|
693 |
<I>~Sync_handler</I> delays subsequent processing until any pending
|
|
|
694 |
exceptions have been raised, as necessary to synchronise exception
|
|
|
695 |
handler modification. It must be applied immediately prior to any
|
|
|
696 |
action that modifies the effect of <I>~Throw</I>, such as assignment
|
|
|
697 |
to a variable holding an exception handler as <I>long_jump</I> destination
|
|
|
698 |
Responsibility for the <I>~Sync_handler</I> token definition will
|
|
|
699 |
rest with installers. Responsibility for applying it will normally
|
|
|
700 |
rest with producers.
|
|
|
701 |
<P>
|
|
|
702 |
<H3><A NAME=S16>5.2. TDF Diagnostic Specification</A></H3>
|
|
|
703 |
The <A HREF="../diag/diag1.html">TDF Diagnostic Specification</A>
|
|
|
704 |
is a separate document which describes an extension to TDF, optionally
|
|
|
705 |
used to provide program diagnostic information that can be transformed
|
|
|
706 |
by installers to the form required by popular platform-specific debuggers.
|
|
|
707 |
This extension cannot be considered fully developed and is therefore
|
|
|
708 |
not included as part of standard TDF. Its use for other than DRA's
|
|
|
709 |
C producer has not been considered.
|
|
|
710 |
<P>
|
|
|
711 |
<B>5.2.1.</B> <CODE>~exp_to_source, ~diag_id_scope, ~diag_type_scope,
|
|
|
712 |
~diag_tag_scope</CODE>
|
|
|
713 |
<P>
|
|
|
714 |
<PRE>
|
|
|
715 |
<I>bdy</I>: EXP
|
|
|
716 |
... : ...
|
|
|
717 |
-> EXP
|
|
|
718 |
</PRE>
|
|
|
719 |
Each of these four tokens has several arguments of which the first,
|
|
|
720 |
<I>bdy</I>, is an <CODE>EXP</CODE>. In each case the default definition
|
|
|
721 |
body, when no diagnostic information is required, is simply <I>bdy</I>.
|
|
|
722 |
Note that this description is quite sufficient to enable installers
|
|
|
723 |
to ignore any diagnostic information that may be included in produced
|
|
|
724 |
TDF, without needing any further knowledge of the TDF Diagnostic Specification.
|
|
|
725 |
|
|
|
726 |
<P>
|
|
|
727 |
<H3><A NAME=S17>5.3. Accessing variable parameter lists</A></H3>
|
|
|
728 |
Installers should provide token definitions for the tokens listed
|
|
|
729 |
in this section.
|
|
|
730 |
<P>
|
|
|
731 |
<B>5.3.1.</B> <CODE>~va_list</CODE>
|
|
|
732 |
<P>
|
|
|
733 |
<PRE>
|
|
|
734 |
-> SHAPE
|
|
|
735 |
</PRE>
|
|
|
736 |
This is the <CODE>SHAPE</CODE> of a variable capable of holding state
|
|
|
737 |
information used for stepping through the anonymous parameters of
|
|
|
738 |
a procedure created by <I>make_proc</I>.
|
|
|
739 |
<P>
|
|
|
740 |
<B>5.3.2.</B> <CODE>~__va_start</CODE>
|
|
|
741 |
<P>
|
|
|
742 |
<PRE>
|
|
|
743 |
<I>p</I>: EXP POINTER var_param_alignment
|
|
|
744 |
-> EXP ~va_list
|
|
|
745 |
</PRE>
|
|
|
746 |
If <I>t</I> is the <CODE>TAG</CODE> introduced by <I>var_intro</I>
|
|
|
747 |
<CODE>OPTION(TAGACC)</CODE> in <I>make_proc</I>, then the token application
|
|
|
748 |
<I>~__va_start(obtain_tag(t))</I> will provide the initial value for
|
|
|
749 |
a local variable to be used for stepping through the anonymous parameters
|
|
|
750 |
of the procedure, starting with the first actual parameter (if any)
|
|
|
751 |
that does not have a corresponding entry in the make_proc params_intro
|
|
|
752 |
list.
|
|
|
753 |
<P>
|
|
|
754 |
<B>5.3.3.</B> <CODE>~va_arg</CODE>
|
|
|
755 |
<P>
|
|
|
756 |
<PRE>
|
|
|
757 |
<I>v</I>: EXP POINTER (alignment(~va_list))
|
|
|
758 |
<I>s</I>: SHAPE
|
|
|
759 |
-> EXP <I>s</I>
|
|
|
760 |
</PRE>
|
|
|
761 |
If <I>v</I> is the variable initialised by <I>~__va_start </I>(see
|
|
|
762 |
above), then successive token applications <I>~va_arg(v,s)</I>
|
|
|
763 |
will deliver the anonymous parameter values in turn. The successive
|
|
|
764 |
<CODE>SHAPE</CODE>s <I>s</I> must be the appropriate <CODE>SHAPE</CODE>s
|
|
|
765 |
for the successive parameters.
|
|
|
766 |
<P>
|
|
|
767 |
<B>5.3.4.</B> <CODE>~va_end</CODE>
|
|
|
768 |
<P>
|
|
|
769 |
<PRE>
|
|
|
770 |
<I>v</I>: EXP POINTER (alignment(~va_list))
|
|
|
771 |
-> EXP TOP
|
|
|
772 |
</PRE>
|
|
|
773 |
If <I>v</I> is a variable initialised by <I>~__va_start</I>, the token
|
|
|
774 |
application <I>~va_end(v)</I> indicates that no further use will be
|
|
|
775 |
made of <I>v</I>.
|
|
|
776 |
<P>
|
|
|
777 |
<B>5.3.5.</B> <CODE>~next_caller_offset</CODE>
|
|
|
778 |
<P>
|
|
|
779 |
<PRE>
|
|
|
780 |
<I>o1</I>: EXP OFFSET (<I>fa</I>,parameter_alignment(<I>s1</I>))
|
|
|
781 |
<I>s1</I>: SHAPE
|
|
|
782 |
<I>s2</I>: SHAPE
|
|
|
783 |
-> EXP OFFSET (<I>fa</I>,parameter_alignment(<I>s2</I>))
|
|
|
784 |
</PRE>
|
|
|
785 |
<I>~next_caller_offset</I> is used to provide access to successive
|
|
|
786 |
elements of the <I>caller_params</I> of an <I>apply_general_proc</I>,
|
|
|
787 |
by delivering successive <CODE>OFFSET</CODE>s of their positions relative
|
|
|
788 |
to the environment pointer created by that procedure application.
|
|
|
789 |
Both the
|
|
|
790 |
<I>apply_general_proc</I> and associated <I>make_general_proc</I>
|
|
|
791 |
will include <CODE>PROCPROPS</CODE> <I>var_callers</I>.
|
|
|
792 |
<P>
|
|
|
793 |
<I>o1</I> will be the <CODE>OFFSET</CODE> for a <I>caller_params</I>
|
|
|
794 |
element of
|
|
|
795 |
<CODE>SHAPE</CODE> <I>s1</I>, and will be derived either from <I>env_offset</I>
|
|
|
796 |
for a <CODE>TAG</CODE> introduced by <I>caller_intro</I> of the <I>make_general_proc
|
|
|
797 |
</I>, or from a previous application of <I>~next_caller_offset</I>.
|
|
|
798 |
<I>s2</I>
|
|
|
799 |
will be the <CODE>SHAPE</CODE> of the subsequent <I>caller_params</I>
|
|
|
800 |
element, whose <CODE>OFFSET</CODE> is delivered. <I>fa</I> will include
|
|
|
801 |
the set union of
|
|
|
802 |
<CODE>ALIGNMENT</CODE>s appropriate to the <I>make_general_proc</I>
|
|
|
803 |
(as specified by <I>current_env</I>).
|
|
|
804 |
<P>
|
|
|
805 |
<B>5.3.6.</B> <CODE>~next_callee_offset</CODE>
|
|
|
806 |
<P>
|
|
|
807 |
<PRE>
|
|
|
808 |
<I>o1</I>: EXP OFFSET (<I>fa</I>,parameter_alignment(<I>s1</I>))
|
|
|
809 |
<I>s1</I>: SHAPE
|
|
|
810 |
<I>s2</I>: SHAPE
|
|
|
811 |
-> EXP OFFSET (<I>fa</I>,parameter_alignment(<I>s2</I>))
|
|
|
812 |
</PRE>
|
|
|
813 |
<I>~next_callee_offset</I> is used to provide access to successive
|
|
|
814 |
elements of the <CODE>CALLEES</CODE> of an <I>apply_general_proc</I>
|
|
|
815 |
or <I>tail_call</I>, by delivering successive <CODE>OFFSET</CODE>s
|
|
|
816 |
of their positions relative to the environment pointer created by
|
|
|
817 |
that procedure application. Both the procedure application and associated
|
|
|
818 |
<I>make_general_proc</I> will include <CODE>PROCPROPS</CODE> <I>var_callees</I>.
|
|
|
819 |
|
|
|
820 |
<P>
|
|
|
821 |
<I>o1</I> will be the <CODE>OFFSET</CODE> for a <CODE>CALLEES</CODE>
|
|
|
822 |
element of <CODE>SHAPE</CODE> <I>s1</I>, and will be derived either
|
|
|
823 |
from <I>env_offset</I> for a <CODE>TAG</CODE> introduced by <I>callee_intro</I>
|
|
|
824 |
of the <I>make_general_proc</I>, or from a previous application of
|
|
|
825 |
<I>~next_callee_offset</I>. <I>s2</I>
|
|
|
826 |
will be the <CODE>SHAPE</CODE> of the subsequent <CODE>CALLEES</CODE>
|
|
|
827 |
element, whose <CODE>OFFSET</CODE>
|
|
|
828 |
is delivered. <I>fa</I> will include the set union of <CODE>ALIGNMENT</CODE>s
|
|
|
829 |
appropriate to the <I>make_general_proc</I> (as specified by <I>current_env
|
|
|
830 |
</I>).
|
|
|
831 |
<P>
|
|
|
832 |
|
|
|
833 |
<HR>
|
|
|
834 |
<H2><A NAME=S18>6. Language Programming Interfaces</A></H2>
|
|
|
835 |
A Language Programming Interface (LPI) is here defined to mean a set
|
|
|
836 |
of tokens, usually specific to a particular producer, which will encapsulate
|
|
|
837 |
language features at a higher level than basic TDF constructs, more
|
|
|
838 |
convenient for the producer to produce.
|
|
|
839 |
<P>
|
|
|
840 |
Responsibility for the specification of individual LPIs lies with
|
|
|
841 |
the appropriate producer itself. Before an application can be installed
|
|
|
842 |
on some target platform, the appropriate LPI token definitions must
|
|
|
843 |
have been built for that platform. In this sense, the LPI can be considered
|
|
|
844 |
as a primitive API, which is discussed in section <A HREF="#S21">7</A>.
|
|
|
845 |
<P>
|
|
|
846 |
The process by which the LPI token definition library or capsule is
|
|
|
847 |
generated for any specific platform will vary according to the LPI,
|
|
|
848 |
and responsibility for defining that process will also lie with the
|
|
|
849 |
appropriate producer. Some LPIs, such as that associated with DRA's
|
|
|
850 |
C producer, can be fully defined by architecture neutral TDF, using
|
|
|
851 |
the tokens specified in sections <A HREF="#S6">3</A> and <A HREF="#S11">4</A>
|
|
|
852 |
to encapsulate any target dependencies. When that is the case, the
|
|
|
853 |
generation process can be fully automated. For other LPIs the process
|
|
|
854 |
may be much less automated. In some cases where the source language
|
|
|
855 |
implies a complex run-time system, this might even require a small
|
|
|
856 |
amount of new code to be written for each platform.
|
|
|
857 |
<P>
|
|
|
858 |
Generally, the individual LPI tokens do not need to be specified in
|
|
|
859 |
the token registry, provided they follow a registered naming scheme
|
|
|
860 |
to ensure uniqueness (see section <A HREF="#S5">2</A>). In exceptional
|
|
|
861 |
circumstances it may be necessary for some TDF tool to recognise individual
|
|
|
862 |
LPI tokens explicitly by name. This will be the case when experimenting
|
|
|
863 |
with potential extensions to TDF, in the field of parallelism for
|
|
|
864 |
example. In other cases a TDF installer or other tool may recognise
|
|
|
865 |
an LPI token by name rather than its definition by choice, for some
|
|
|
866 |
unspecified advantage. We make a pragmatic choice in such cases whether
|
|
|
867 |
to include such token specifications in the token registry. For widely
|
|
|
868 |
used producers, we can assume availability of the LPI token specifcations,
|
|
|
869 |
or standard definitions, separately from the token register, but we
|
|
|
870 |
should expect any such tokens to be specified within the register
|
|
|
871 |
for all cases where significant advantage could be taken by an installer
|
|
|
872 |
only if it recognises the token by name.
|
|
|
873 |
<P>
|
|
|
874 |
<H3><A NAME=S19>6.1. The DRA C LPI</A></H3>
|
|
|
875 |
DRA's C producer LPI is defined by an architecture neutral token definition
|
|
|
876 |
capsule provided with the producer. Target specific detail is included
|
|
|
877 |
only by use of the target dependency tokens and C mapping tokens specified
|
|
|
878 |
in sections <A HREF="#S6">3</A> and <A HREF="#S12">4.1</A> respectively.
|
|
|
879 |
Target specific versions of this capsule are obtained by transformation,
|
|
|
880 |
using the `preprocessing' action of the TDF tool <I>tnc</I>, with
|
|
|
881 |
definitions of the target dependency and C mapping tokens that are
|
|
|
882 |
provided with the target installer. No special treatment is required
|
|
|
883 |
for any of the C LPI tokens, though translation time can be slightly
|
|
|
884 |
improved in a few cases if the names are recognised and standard token
|
|
|
885 |
definition exercised explicitly within some installers.
|
|
|
886 |
<P>
|
|
|
887 |
The DRA C LPI does not include standard library features, for which
|
|
|
888 |
the C language requires header files. The standard C library is one
|
|
|
889 |
example of an API, discussed in section <A HREF="#S21">7</A>.
|
|
|
890 |
<P>
|
|
|
891 |
<H3><A NAME=S191>6.2. The DRA C++ LPI</A></H3>
|
|
|
892 |
The DRA C++ LPI extends the DRA C LPI adding tokens for target specific
|
|
|
893 |
C++ features not found in C. Again, standard library features are
|
|
|
894 |
treated as an API.
|
|
|
895 |
<H3><A NAME=S20>6.3. The Etnoteam Fortran LPI</A></H3>
|
|
|
896 |
The details in this subsection are provisional, subject to confirmation
|
|
|
897 |
of argument and result <CODE>SORT</CODE>s, and development of model
|
|
|
898 |
token definitions.
|
|
|
899 |
<P>
|
|
|
900 |
The following tokens are named here in case any installers may be
|
|
|
901 |
able to produce better code than could be achieved by normal token
|
|
|
902 |
expansion. In particular, some installers may be able to inline standard
|
|
|
903 |
function calls.
|
|
|
904 |
<UL>
|
|
|
905 |
<LI><I>.Et~SQRT</I>: square root of any floating variety, including
|
|
|
906 |
complex.
|
|
|
907 |
<LI><I>.Et~<CODE>EXP</CODE></I>: exponential (<I>e ** x</I>) of any
|
|
|
908 |
floating variety, including complex.
|
|
|
909 |
<LI><I>.Et~LOG</I>: (natural) logarithm of any floating variety, including
|
|
|
910 |
complex.
|
|
|
911 |
<LI><I>.Et~LOG_10</I>: base 10 logarithm of any floating variety,
|
|
|
912 |
including complex.
|
|
|
913 |
<LI><I>.Et~LOG_2</I>: base 2 logarithm of any floating variety, including
|
|
|
914 |
complex.
|
|
|
915 |
<LI><I>.Et~SIN</I>: sine of any floating variety, including complex.
|
|
|
916 |
<LI><I>.Et~COS</I>: cosine of any floating variety, including complex.
|
|
|
917 |
<LI><I>.Et~TAN</I>: tangent of any floating variety, including complex.
|
|
|
918 |
<LI><I>.Et~ASIN</I>: inverse sine of any floating variety, including
|
|
|
919 |
complex.
|
|
|
920 |
<LI><I>.Et~ACOS</I>: inverse cosine of any floating variety, including
|
|
|
921 |
complex.
|
|
|
922 |
<LI><I>.Et~ATAN</I>: inverse (one argument) tangent of any floating
|
|
|
923 |
variety, including complex.
|
|
|
924 |
<LI><I>.Et~ATAN2</I>: inverse (two arguments) tangent of any floating
|
|
|
925 |
variety, excluding complex.
|
|
|
926 |
<LI><I>.Et~SINH</I>: hyperbolic sine of any floating variety, including
|
|
|
927 |
complex.
|
|
|
928 |
<LI><I>.Et~COSH</I>: hyperbolic cosine of any floating variety, including
|
|
|
929 |
complex.
|
|
|
930 |
<LI><I>.Et~TANH</I>: hyperbolic tangent of any floating variety, including
|
|
|
931 |
complex.
|
|
|
932 |
<LI><I>.Et~ASINH</I>: inverse hyperbolic sine of any floating variety,
|
|
|
933 |
including complex.
|
|
|
934 |
<LI><I>.Et~ACOSH</I>: inverse hyperbolic cosine of any floating variety,
|
|
|
935 |
including complex.
|
|
|
936 |
<LI><I>.Et~ATANH</I>: inverse hyperbolic tangent of any floating variety,
|
|
|
937 |
including complex.
|
|
|
938 |
<LI><I>.Et~MOD</I>: floating point remainder of any floating variety,
|
|
|
939 |
excluding complex.
|
|
|
940 |
</UL>
|
|
|
941 |
|
|
|
942 |
<P>
|
|
|
943 |
|
|
|
944 |
<HR>
|
|
|
945 |
<H2><A NAME=S21>7. Application Programming Interfaces</A></H2>
|
|
|
946 |
Application Programming Interfaces are typically specified with a
|
|
|
947 |
C mapping, which define the required contents for C header files which
|
|
|
948 |
a portable C program must include by name to gain access to target
|
|
|
949 |
specific implementations of an API library. The TDF approach to API
|
|
|
950 |
specification includes using a #pragma token syntax within architecture
|
|
|
951 |
neutral C header files, such that all implementation dependencies
|
|
|
952 |
are encapsulated by API specific tokens. These API tokens are the
|
|
|
953 |
TDF representation of the API. Both the API library and API token
|
|
|
954 |
definitions are required before a TDF program using the API can be
|
|
|
955 |
installed on any particular platform.
|
|
|
956 |
<P>
|
|
|
957 |
Platform specific definitions for API tokens are produced automatically,
|
|
|
958 |
with few exceptions, for any platform with a conformant implementation
|
|
|
959 |
of the API. This is achieved by a token library building process which
|
|
|
960 |
analyses the architecture neutral header files for the API concerned,
|
|
|
961 |
together with the platform specific header files that provide normal
|
|
|
962 |
(non-TDF) C access to the API. The few exceptions occur where the
|
|
|
963 |
platform specific header files have been written to make use of specific
|
|
|
964 |
C compiler built-in features, typically recognised by identifiers
|
|
|
965 |
with a prefix such as `<I>__builtin_</I>'. Such cases are very likely
|
|
|
966 |
to require explicit recognition of the corresponding token name in
|
|
|
967 |
TDF installers.
|
|
|
968 |
<P>
|
|
|
969 |
Generally, API token names and specifications are not detailed in
|
|
|
970 |
this token register. The token specifications are clearly dependent
|
|
|
971 |
on the associated API specifications. Authority for controlling the
|
|
|
972 |
actual API token names, and the relationship between API tokens and
|
|
|
973 |
the various API standardisation authorities, remain separate subjects
|
|
|
974 |
of discussion.
|
|
|
975 |
<P>
|
|
|
976 |
Names and specifications are given or implied below for those API
|
|
|
977 |
tokens which frequently require built-in support from installers,
|
|
|
978 |
and for other cases where an installer may be able to produce better
|
|
|
979 |
code than could be achieved by normal token expansion, for example
|
|
|
980 |
by inlining standard function calls.
|
|
|
981 |
<P>
|
|
|
982 |
<H3><A NAME=S22>7.1. ANSI C standard functions</A></H3>
|
|
|
983 |
The set of tokens implied below all have the form:
|
|
|
984 |
<P>
|
|
|
985 |
<B>7.1.1.</B> <CODE>ansi.<I>header</I>.<I>function</I></CODE>
|
|
|
986 |
<P>
|
|
|
987 |
<PRE>
|
|
|
988 |
... : ...
|
|
|
989 |
-> EXP
|
|
|
990 |
</PRE>
|
|
|
991 |
Tokens are defined for all cases where <I>header</I> is ctype or string
|
|
|
992 |
or math or stdlib, and <I>function</I> is the name of a non-ellipsis
|
|
|
993 |
function specified in the ANSI C standard library, declared within
|
|
|
994 |
the corresponding header <<I>header</I>.h>. (Note that ellipsis
|
|
|
995 |
functions, such as <I>printf</I>, cannot be represented as tokens
|
|
|
996 |
since they may take a variable number of arguments.)
|
|
|
997 |
<P>
|
|
|
998 |
These tokens have arguments all of <CODE>SORT</CODE> <CODE>EXP</CODE>,
|
|
|
999 |
whose number and shape, and token result shape, all correspond to
|
|
|
1000 |
the implementation shape of the named ANSI C standard library function
|
|
|
1001 |
parameters and result. For the few cases where the function is specified
|
|
|
1002 |
not to return (e.g. <I>ansi.stdlib.abort</I>), the result shape may
|
|
|
1003 |
be either <CODE>TOP</CODE> or <CODE>BOTTOM</CODE>.
|
|
|
1004 |
<P>
|
|
|
1005 |
<H3><A NAME=S23>7.2. Common exceptional cases</A></H3>
|
|
|
1006 |
<B>7.2.1.</B> <CODE>ansi.setjmp.setjmp</CODE>
|
|
|
1007 |
<P>
|
|
|
1008 |
<PRE>
|
|
|
1009 |
<I>jb</I>: EXP
|
|
|
1010 |
-> EXP
|
|
|
1011 |
</PRE>
|
|
|
1012 |
<I>ansi.setjmp.setjmp</I> is a token which has the semantics and argument
|
|
|
1013 |
and result implementation shapes corresponding to the ANSI C macro
|
|
|
1014 |
<I>setjmp</I> declared within <setjmp.h>.
|
|
|
1015 |
<P>
|
|
|
1016 |
<B>7.2.2.</B> <CODE>ansi.setjmp.longjmp</CODE>
|
|
|
1017 |
<P>
|
|
|
1018 |
<PRE>
|
|
|
1019 |
<I>jb</I>: EXP
|
|
|
1020 |
<I>v</I>: EXP
|
|
|
1021 |
-> EXP
|
|
|
1022 |
</PRE>
|
|
|
1023 |
<I>ansi.setjmp.longjmp</I> is a token which has the semantics and
|
|
|
1024 |
argument implementation shapes corresponding to the ANSI C macro <I>longjmp
|
|
|
1025 |
</I> declared within <setjmp.h>. The result shape may be either
|
|
|
1026 |
TOP or BOTTOM.
|
|
|
1027 |
<P>
|
|
|
1028 |
<B>7.2.3.</B> <CODE>~alloca</CODE>
|
|
|
1029 |
<P>
|
|
|
1030 |
<PRE>
|
|
|
1031 |
<I>i</I>: EXP
|
|
|
1032 |
-> EXP
|
|
|
1033 |
</PRE>
|
|
|
1034 |
<I>~alloca</I> is a token which has the semantics and argument and
|
|
|
1035 |
result implementation shapes corresponding to the BSD specified function
|
|
|
1036 |
<I>alloca</I>.
|
|
|
1037 |
<P>
|
|
|
1038 |
<B>7.2.4.</B> <CODE>ansi.stdarg.va_list, ansi.stdarg.__va_start,
|
|
|
1039 |
ansi.stdarg.va_arg, ansi.stdarg.va_end</CODE>
|
|
|
1040 |
<P>
|
|
|
1041 |
These four tokens are identical to the Interface Tokens <I>~va_list</I>,
|
|
|
1042 |
<I>~__va_start</I>, <I>~va_arg</I> and <I>~va_end</I> respectively.
|
|
|
1043 |
<P>
|
|
|
1044 |
<HR>
|
|
|
1045 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
1046 |
Copyright © 1998.</I></P>
|
|
|
1047 |
</BODY>
|
|
|
1048 |
</HTML>
|