| 6 |
7u83 |
1 |
<?xml version="1.0" standalone="no"?>
|
|
|
2 |
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
|
3 |
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
|
|
4 |
|
|
|
5 |
<!--
|
|
|
6 |
$Id$
|
|
|
7 |
-->
|
|
|
8 |
|
|
|
9 |
<book>
|
|
|
10 |
<bookinfo>
|
|
|
11 |
<title>PL_TDF Definition</title>
|
|
|
12 |
|
|
|
13 |
<corpauthor>The TenDRA Project</corpauthor>
|
|
|
14 |
|
|
|
15 |
<author>
|
|
|
16 |
<firstname>Jeroen</firstname>
|
|
|
17 |
<surname>Ruigrok van der Werven</surname>
|
|
|
18 |
</author>
|
|
|
19 |
<authorinitials>JRvdW</authorinitials>
|
|
|
20 |
<pubdate>2005</pubdate>
|
|
|
21 |
|
|
|
22 |
<copyright>
|
|
|
23 |
<year>2004</year>
|
|
|
24 |
<year>2005</year>
|
|
|
25 |
|
|
|
26 |
<holder>The TenDRA Project</holder>
|
|
|
27 |
</copyright>
|
|
|
28 |
|
|
|
29 |
<copyright>
|
|
|
30 |
<year>1998</year>
|
|
|
31 |
|
|
|
32 |
<holder>DERA</holder>
|
|
|
33 |
</copyright>
|
|
|
34 |
</bookinfo>
|
|
|
35 |
|
|
|
36 |
<chapter id="intro">
|
|
|
37 |
<title>Introduction</title>
|
|
|
38 |
|
|
|
39 |
<para>PL_TDF is a language in the lineage of Wirth's PL360 and its later
|
|
|
40 |
derivatives. The basic idea in PL360 was to give one an assembler in
|
|
|
41 |
which one could express all of the order-code of the IBM 360 while
|
|
|
42 |
still preserving the logical structure of the program using familiar
|
|
|
43 |
programming constructs. If one had to produce a program at the code
|
|
|
44 |
level, this approach was much preferable to writing "flat" assembly
|
|
|
45 |
code using a traditional assembler, as anyone who has used both can
|
|
|
46 |
testify.</para>
|
|
|
47 |
|
|
|
48 |
<para>In the TDF "machine" the problem is not lack of structure at its
|
|
|
49 |
"assembly" level, but rather too much of it; one loses the sense of a
|
|
|
50 |
TDF program because of its deeply nested structure. Also the naming
|
|
|
51 |
conventions of TDF are designed to make them tractable to machine
|
|
|
52 |
manipulation, rather than human reading and writing. However, the
|
|
|
53 |
approach is basically the same. PL_TDF provides shorthand notations
|
|
|
54 |
for the commonly occuring control structures and operations while
|
|
|
55 |
still allowing one to use the standard TDF constructors which, in
|
|
|
56 |
turn, may have shorthand notations for their parameters. The naming is
|
|
|
57 |
always done by identifiers where the sort of the name is determined by
|
|
|
58 |
its declaration, or by context.</para>
|
|
|
59 |
|
|
|
60 |
<para>The TDF derived from PL_TDF is guaranteed to be SORT correct;
|
|
|
61 |
however, there is no SHAPE checking, so one can still make illegal
|
|
|
62 |
TDF.</para>
|
|
|
63 |
</chapter>
|
|
|
64 |
|
|
|
65 |
<chapter>
|
|
|
66 |
<title>Notation</title>
|
|
|
67 |
|
|
|
68 |
<sect1 id="S3">
|
|
|
69 |
<title>Syntax description</title>
|
|
|
70 |
|
|
|
71 |
<para>Words enclosed in angle brackets, < >, form non-terminal
|
|
|
72 |
symbols. Other symbols and words stand for themselves as terminal
|
|
|
73 |
symbols. An expansion of a non-terminal is indicated using ::= with
|
|
|
74 |
its expansion given as a sequence (possibly empty) of terminals and
|
|
|
75 |
non-terminals. For example:
|
|
|
76 |
<programlisting>
|
|
|
77 |
<Exp> ::= * <ident>
|
|
|
78 |
</programlisting>
|
|
|
79 |
is a possible expansion of an EXP SORT. If the word for the
|
|
|
80 |
non-terminal starts with a capital letter then it will be totally
|
|
|
81 |
described by a set of such expansions; otherwise the expansion of
|
|
|
82 |
the non-terminal will be given by other methods in the text.</para>
|
|
|
83 |
|
|
|
84 |
<para>The post-fix -Opt on a non terminal is an abreviation allowing
|
|
|
85 |
an empty expansion. For example:
|
|
|
86 |
<programlisting>
|
|
|
87 |
<Access>-Opt
|
|
|
88 |
</programlisting>
|
|
|
89 |
is equivalent to the use of another non-terminal
|
|
|
90 |
<AccessOption> whose expansions are:
|
|
|
91 |
<programlisting>
|
|
|
92 |
<AccessOption> ::=
|
|
|
93 |
<AccessOption> ::= <Access>
|
|
|
94 |
</programlisting>
|
|
|
95 |
The post-fix -List on a non terminal is an abreviation for lists of
|
|
|
96 |
objects seperated by the ,-symbol. For example:
|
|
|
97 |
<programlisting>
|
|
|
98 |
<Exp>-List
|
|
|
99 |
</programlisting>
|
|
|
100 |
is equivalent to the use of another non-terminal <ExpList>
|
|
|
101 |
whose expansions are:
|
|
|
102 |
<programlisting>
|
|
|
103 |
<ExpList> ::= <Exp>
|
|
|
104 |
<ExpList> ::= <ExpList> , <Exp>
|
|
|
105 |
</programlisting>
|
|
|
106 |
Both of these post-fix notations are also used with sequences of
|
|
|
107 |
terminals and non-terminals within the angle brackets with the same
|
|
|
108 |
kind of expansion. In these cases, the expansion within the angle
|
|
|
109 |
brackets form an anonymous non-terminal.</para>
|
|
|
110 |
</sect1>
|
|
|
111 |
|
|
|
112 |
<sect1 id="S4">
|
|
|
113 |
<title>Lexical Units</title>
|
|
|
114 |
|
|
|
115 |
<para>The terminal symbols ( ), [ ], and { } always occur as
|
|
|
116 |
parenthetic pairs and never form part of other terminal
|
|
|
117 |
symbols.</para>
|
|
|
118 |
|
|
|
119 |
<para>The terminal symbols , ; and : are similarly terminators for
|
|
|
120 |
other terminal symbols.</para>
|
|
|
121 |
|
|
|
122 |
<para>White space is a terminator for other terminal symbols but is
|
|
|
123 |
otherwise ignored except in strings.</para>
|
|
|
124 |
|
|
|
125 |
<para>All other terminal symbols are sequences of ACSII symbols not
|
|
|
126 |
including the above. These are divided into seven classes: keywords,
|
|
|
127 |
TDF constructors, operators, <integer_denotation>s,
|
|
|
128 |
<floating_denotation>s, <string>s and
|
|
|
129 |
<ident>s.</para>
|
|
|
130 |
|
|
|
131 |
<para>The keywords and operators are expressed directly in the syntax
|
|
|
132 |
description. The TDF constructors are those given in the TDF
|
|
|
133 |
specification which have first-class SORTs as parameters and
|
|
|
134 |
results.</para>
|
|
|
135 |
|
|
|
136 |
<para>An <integer_denotatation> allows one to express an integer
|
|
|
137 |
in any base less than 16, with the default being 10.
|
|
|
138 |
<programlisting>
|
|
|
139 |
<integer_denotation> ::= <digit>
|
|
|
140 |
<integer_denotation> ::= <integer_denotation> <digit>
|
|
|
141 |
<integer_denotation> ::= <base> <integer_denotation>
|
|
|
142 |
|
|
|
143 |
<base> ::= <integer_denotation> r
|
|
|
144 |
</programlisting>
|
|
|
145 |
Examples are 31, 16r1f, 8r37, 2r11111 - all giving the same
|
|
|
146 |
value.</para>
|
|
|
147 |
|
|
|
148 |
<para>A <floating_denotation> is an <integer_denotation>
|
|
|
149 |
followed by the . symbol and a sequence of digits. The radix of the
|
|
|
150 |
<floating_denotation> is given by the base of its component
|
|
|
151 |
<integer_denotation></para>
|
|
|
152 |
|
|
|
153 |
<para>A <string> is the same as a C string - any sequence of
|
|
|
154 |
characters within " ". The same C conventions hold for \ within
|
|
|
155 |
strings for single characters.</para>
|
|
|
156 |
|
|
|
157 |
<para>A <character> is an string character within ` `. The same
|
|
|
158 |
\ conventions hold.</para>
|
|
|
159 |
|
|
|
160 |
<para>An <ident> is any other sequence of characters. They will
|
|
|
161 |
be used to form names for TAGs, TOKENs, AL_TAGs and LABELs.</para>
|
|
|
162 |
</sect1>
|
|
|
163 |
|
|
|
164 |
<sect1 id="S5">
|
|
|
165 |
<title>Pre-processing</title>
|
|
|
166 |
|
|
|
167 |
<para>At the moment there is only one pre-processing directive. A line
|
|
|
168 |
starting with #include will textually include the following file
|
|
|
169 |
(named within string quotes), using the same path conventions as
|
|
|
170 |
C.</para>
|
|
|
171 |
|
|
|
172 |
<para>Comments may be included in the text using the /* ... */
|
|
|
173 |
notation; this differs slightly from the C convention in that
|
|
|
174 |
comments may be nested.</para>
|
|
|
175 |
</sect1>
|
|
|
176 |
</chapter>
|
|
|
177 |
|
|
|
178 |
<chapter>
|
|
|
179 |
<title>The Language</title>
|
|
|
180 |
|
|
|
181 |
<para>The basic philosophy of PL_TDF is to provide the "glue"
|
|
|
182 |
constructors of TDF automatically, while still allowing the programmer
|
|
|
183 |
to use the significant constructors in their most general form. By
|
|
|
184 |
"glue" constructors, I mean those like make_link, make_group etc.
|
|
|
185 |
which are there to provide tedious, but vital, constructions concerned
|
|
|
186 |
with linking and naming. The "significant" constructors really come in
|
|
|
187 |
two groups, depending on their resulting SORTs. There are those SORTs
|
|
|
188 |
like TOKDEC, whose SORTs are purely syntactic and can't be used as
|
|
|
189 |
results of token applications or _cond constructions. On the other
|
|
|
190 |
hand, the first-class SORTs, like EXP, can be used in those situations
|
|
|
191 |
and generally have a much richer set of constructors. These
|
|
|
192 |
first-class SORTs are precisely those which have SORTNAMEs. These
|
|
|
193 |
SORTNAMEs appear in PL_TDF as expansions of <Sortname>:
|
|
|
194 |
<programlisting>
|
|
|
195 |
<Sortname> ::= ACCESS
|
|
|
196 |
<Sortname> ::= AL_TAG
|
|
|
197 |
<Sortname> ::= ALIGNMENT
|
|
|
198 |
<Sortname> ::= BITFIELD_VARIETY
|
|
|
199 |
<Sortname> ::= BOOL
|
|
|
200 |
<Sortname> ::= ERROR_TREATMENT
|
|
|
201 |
<Sortname> ::= EXP
|
|
|
202 |
<Sortname> ::= FLOATING_VARIETY
|
|
|
203 |
<Sortname> ::= LABEL
|
|
|
204 |
<Sortname> ::= NAT
|
|
|
205 |
<Sortname> ::= NTEST
|
|
|
206 |
<Sortname> ::= ROUNDING_MODE
|
|
|
207 |
<Sortname> ::= SHAPE
|
|
|
208 |
<Sortname> ::= SIGNED_NAT
|
|
|
209 |
<Sortname> ::= STRING
|
|
|
210 |
<Sortname> ::= TAG
|
|
|
211 |
<Sortname> ::= TRANSFER_MODE
|
|
|
212 |
<Sortname> ::= VARIETY
|
|
|
213 |
</programlisting>
|
|
|
214 |
All of the significant constructors are expanded by non-terminals with
|
|
|
215 |
names related to their resulting SORT e.g. all EXPs are expanded by
|
|
|
216 |
<Exp> and all TOKDECs are expanded by <Tokdec>. Any
|
|
|
217 |
first-class SORT can be expanded by using the constructor names given
|
|
|
218 |
in the TDF specification, provided that the parameter SORTs are also
|
|
|
219 |
first-class. For example, the following are all valid expansions of
|
|
|
220 |
<Exp> :
|
|
|
221 |
<programlisting>
|
|
|
222 |
make_top
|
|
|
223 |
return(E) where E is an expansion of <Exp>
|
|
|
224 |
goto(L) where L is an expansion of <Label>
|
|
|
225 |
assign(E1, E2) where E1 and E2 are expansions of <Exp>
|
|
|
226 |
</programlisting>
|
|
|
227 |
Any such use of TDF constructors will be checked for the
|
|
|
228 |
SORT-correctness of their parameters. I will denote such a constructor
|
|
|
229 |
as an <exp_constructor>; similarly for all the other first-class
|
|
|
230 |
sorts.</para>
|
|
|
231 |
|
|
|
232 |
<para>Any of the first-class sorts may also be expanded by a token
|
|
|
233 |
application. Tokens in PL_TDF are given <ident> names by
|
|
|
234 |
<Tokdef> or <Tokdec> which must occur before their use in
|
|
|
235 |
applications. In applications, these names will be denoted by
|
|
|
236 |
<exp_token>, <shape_token> etc. , depending on the result
|
|
|
237 |
sort of their introduction.</para>
|
|
|
238 |
|
|
|
239 |
<para>The principle of "no use before declaration" also applies to
|
|
|
240 |
<ident> names given to TAGs.</para>
|
|
|
241 |
|
|
|
242 |
<sect1 id="S7">
|
|
|
243 |
<title>Program</title>
|
|
|
244 |
|
|
|
245 |
<para>The root expansion of a PL_TDF program is given by
|
|
|
246 |
<Program>:
|
|
|
247 |
<programlisting>
|
|
|
248 |
<Program> ::= <ElementList> Keep ( <Item>-List-Opt )
|
|
|
249 |
|
|
|
250 |
<ElementList> ::= <Element> ;
|
|
|
251 |
<ElementList> ::= <Element> ; <ElementList>
|
|
|
252 |
|
|
|
253 |
<Element> ::= <Tokdec>
|
|
|
254 |
<Element> ::= <Tokdef>
|
|
|
255 |
<Element> ::= <Tagdec>
|
|
|
256 |
<Element> ::= <Tagdef>
|
|
|
257 |
<Element> ::= <Altagdef>
|
|
|
258 |
<Element> ::= <Structdef>
|
|
|
259 |
<Element> ::= <Procdef>
|
|
|
260 |
|
|
|
261 |
<Item> ::= <tag>
|
|
|
262 |
<Item> ::= <token>
|
|
|
263 |
<item> ::= <altag>
|
|
|
264 |
</programlisting>
|
|
|
265 |
A <Program> consists of a list of definitions and declarations
|
|
|
266 |
giving meaning to various <ident>s, as TAGs, TOKENs and
|
|
|
267 |
AL_TAGs. The <Item>-List-Opt indicates which of these names
|
|
|
268 |
will be externally available via CAPSULE_LINKs; in addition any
|
|
|
269 |
other names which are declared but not defined will also be linked
|
|
|
270 |
externally.</para>
|
|
|
271 |
|
|
|
272 |
<para>A <Program> will produce a single TDF CAPSULE.</para>
|
|
|
273 |
|
|
|
274 |
<sect2 id="S8">
|
|
|
275 |
<title>Tokdec</title>
|
|
|
276 |
|
|
|
277 |
<para>A <Tokdec> introduces an <ident> as a TOKEN:
|
|
|
278 |
<programlisting>
|
|
|
279 |
<Tokdec> ::= Tokdec <ident><Signature>: [ <TokDecPar>-List-Opt ] <ResultSort>
|
|
|
280 |
|
|
|
281 |
<ResultSort> ::= <Sortname>
|
|
|
282 |
<TokDecPar> ::= <Sortname>
|
|
|
283 |
<TokDecPar> ::= TOKEN [ <TokDecPar>-List-Opt ] <ResultSort>
|
|
|
284 |
<Signature> ::= <String>-Opt
|
|
|
285 |
</programlisting>
|
|
|
286 |
This produces a TOKDEC in a tokdec UNIT of the CAPSULE. Further
|
|
|
287 |
uses of the introduced <ident> will be treated as a
|
|
|
288 |
<x-token> where x is given by the <ResultSort>.</para>
|
|
|
289 |
</sect2>
|
|
|
290 |
|
|
|
291 |
<sect2 id="S9">
|
|
|
292 |
<title>Tokdef</title>
|
|
|
293 |
|
|
|
294 |
<para>A <Tokdef> defines an <ident> as a TOKEN; this
|
|
|
295 |
<ident> may have previously been introduced by a
|
|
|
296 |
<Tokdec>:
|
|
|
297 |
<programlisting>
|
|
|
298 |
<Tokdef> ::= Tokdef <ident><Signature> = <Tok_Defn>
|
|
|
299 |
|
|
|
300 |
<Tok_Defn> ::= [ <TokDefPar>-List-Opt ] <ResultSort> <result_sort>
|
|
|
301 |
<TokDefPar> ::= <ident> : <TokDecPar>
|
|
|
302 |
<Signature> ::= <String>-Opt
|
|
|
303 |
</programlisting>
|
|
|
304 |
This produces a TOKDEF in a tokdef UNIT of the CAPSULE. The
|
|
|
305 |
expansion of <result_sort> depends on <ResultSort>,
|
|
|
306 |
e.g. if <ResultSort> is EXP then <result_sort> ::=
|
|
|
307 |
<Exp> and so on.</para>
|
|
|
308 |
|
|
|
309 |
<para>Each of the <ident>s in the <TokDefPar>s will be
|
|
|
310 |
names for tokens whose scope is <result_sort>. A use of such
|
|
|
311 |
a name within its scope will be expanded as a parameterless token
|
|
|
312 |
application of the appropriate sort given by its
|
|
|
313 |
<TokDecPar>. Note that this is still true if the
|
|
|
314 |
<TokDecPar> is a TOKEN - if a <TokDefPar> is:
|
|
|
315 |
<programlisting>
|
|
|
316 |
x: TOKEN[ LABEL ]EXP
|
|
|
317 |
</programlisting>
|
|
|
318 |
then x[L] is expanded as:
|
|
|
319 |
<programlisting>
|
|
|
320 |
exp_apply_token( token_apply_token(x, ()), L)
|
|
|
321 |
</programlisting>
|
|
|
322 |
<Tok_defn> also occurs in an expansion of <Token>, as
|
|
|
323 |
a parameter of a token application.</para>
|
|
|
324 |
</sect2>
|
|
|
325 |
|
|
|
326 |
<sect2 id="S10">
|
|
|
327 |
<title>Tagdec</title>
|
|
|
328 |
|
|
|
329 |
<para>A <Tagdec> introduces an <ident> as a TAG:
|
|
|
330 |
<programlisting>
|
|
|
331 |
<Tagdec> ::= <DecType> <ident> <Signature> <Access>-Opt : <Shape>
|
|
|
332 |
|
|
|
333 |
<DecType> ::= Vardec
|
|
|
334 |
<DecType> ::= Iddec
|
|
|
335 |
<DecType> ::= Commondec
|
|
|
336 |
<Signature> ::= <String>-Opt
|
|
|
337 |
</programlisting>
|
|
|
338 |
This produces a TAGDEC in a tagdec UNIT of the CAPSULE, using a
|
|
|
339 |
make_id_tagdec for the Iddec option, a make_var_tagdec for the
|
|
|
340 |
Vardec option and a common_tagdec for the Commondec option.</para>
|
|
|
341 |
|
|
|
342 |
<para>The <Shape>s in both <Tagdec>s and <Tagdef>s
|
|
|
343 |
will produce SHAPE TOKENs in a tagdef UNIT; these may be applied
|
|
|
344 |
in various shorthand operations on TAG <ident>s.</para>
|
|
|
345 |
</sect2>
|
|
|
346 |
|
|
|
347 |
<sect2 id="S11">
|
|
|
348 |
<title>Tagdef</title>
|
|
|
349 |
|
|
|
350 |
<para>A <Tagdef> defines an <ident> as a TAG. This
|
|
|
351 |
<ident> may have previously been introduced by a
|
|
|
352 |
<Tagdec>; if it has not the < : <Shape> >-Opt
|
|
|
353 |
below must not be empty and a TAGDEC will be produced for it.
|
|
|
354 |
<programlisting>
|
|
|
355 |
<Tagdef> ::= Var <ident><Signature> < : <Shape> >-Opt < = <Exp>>-Opt
|
|
|
356 |
</programlisting>
|
|
|
357 |
Produces a make_var_tagdef.
|
|
|
358 |
<programlisting>
|
|
|
359 |
<Tagdef> ::= Common <ident> <Signature>< : <Shape> >-Opt < = <Exp> >-Opt
|
|
|
360 |
</programlisting>
|
|
|
361 |
Produces a common_tagdef.
|
|
|
362 |
<programlisting>
|
|
|
363 |
<Tagdef> ::= Let <ident><Signature> < : <Shape> >-Opt = <Exp>
|
|
|
364 |
</programlisting>
|
|
|
365 |
Produces a make_id_tagdef.
|
|
|
366 |
<programlisting>
|
|
|
367 |
<Tagdef> ::= String <ident> <Variety>-Opt =<string>
|
|
|
368 |
</programlisting>
|
|
|
369 |
This is a shorthand for producing names which have the properties
|
|
|
370 |
of C strings. The <Variety>-Opt gives the variety of the
|
|
|
371 |
characters with the string, an empty option giving unsigned chars.
|
|
|
372 |
The TDF produced is a make_var_tagdef initialised by a
|
|
|
373 |
make_nof_int. This means that given a String definition:
|
|
|
374 |
<programlisting>
|
|
|
375 |
String format = "Result = %d\n"
|
|
|
376 |
</programlisting>
|
|
|
377 |
the tag <ident>, format, could be used straightforwardly as
|
|
|
378 |
the first parameter of printf - see <link linkend="S41">Section 4
|
|
|
379 |
(Example PL_TDF programs)</link>.</para>
|
|
|
380 |
</sect2>
|
|
|
381 |
|
|
|
382 |
<sect2 id="S12">
|
|
|
383 |
<title>Altagdef</title>
|
|
|
384 |
|
|
|
385 |
<para>An <Altagdef> defines an <ident> as an AL_TAG:
|
|
|
386 |
<programlisting>
|
|
|
387 |
<Altagdef> ::= Al_tagdef <ident> = <Alignment>
|
|
|
388 |
</programlisting>
|
|
|
389 |
This produces an AL_TAGDEF in an al_tagdef UNIT of the CAPSULE. The
|
|
|
390 |
<ident> concerned can be previously used in as an expansion of
|
|
|
391 |
<Alignment>.</para>
|
|
|
392 |
</sect2>
|
|
|
393 |
|
|
|
394 |
<sect2 id="S13">
|
|
|
395 |
<title>Structdef</title>
|
|
|
396 |
|
|
|
397 |
<para>A <Structdef> defines a TOKEN for a structure SHAPE,
|
|
|
398 |
together with two TOKENs for each field of the structure to allow
|
|
|
399 |
easy access to the offsets and contents of the field:
|
|
|
400 |
<programlisting>
|
|
|
401 |
<Structdef> ::= Struct <Structname> ( <Field>-List )
|
|
|
402 |
|
|
|
403 |
<Structname> ::= <ident>
|
|
|
404 |
|
|
|
405 |
<Field> ::= <Fieldname> : <Shape>
|
|
|
406 |
|
|
|
407 |
<Fieldname> ::= <ident>
|
|
|
408 |
</programlisting>
|
|
|
409 |
This produces a TOKDEF in a tokdef UNIT defining
|
|
|
410 |
<Structname> as a SHAPE token whose expansion is an EXP
|
|
|
411 |
OFFSET(a1,a2) where the OFFSET is the size of the structure with
|
|
|
412 |
standard TDF padding and offset addition of the component SHAPEs
|
|
|
413 |
and sizes (note that this may not correspond precisely with C
|
|
|
414 |
sizes).Each <Fieldname> will produce two TOKENs. The first
|
|
|
415 |
is named by <Fieldname> itself and is a [EXP]EXP which gives
|
|
|
416 |
the value of the field of its structure parameter. The second is
|
|
|
417 |
named by prefixing <Fieldname> by the.-symbol and is an [
|
|
|
418 |
]EXP giving the OFFSET of the field from the start of the
|
|
|
419 |
structure. Thus given:
|
|
|
420 |
<programlisting>
|
|
|
421 |
Struct Complex (re: Double, im: Double)
|
|
|
422 |
</programlisting>
|
|
|
423 |
Complex is a TOKEN for a SHAPE defining two Doubles; re[E] and
|
|
|
424 |
im[E] will extract the components of E where E is an EXP of shape
|
|
|
425 |
Complex; .re and.im give EXP OFFSETs of the the two fields from
|
|
|
426 |
the start of the structure.</para>
|
|
|
427 |
</sect2>
|
|
|
428 |
|
|
|
429 |
<sect2 id="S14">
|
|
|
430 |
<title>Procdef</title>
|
|
|
431 |
|
|
|
432 |
<para>A <Procdef> defines a TAG to be a procedure; it is
|
|
|
433 |
simply an abreviation of a an Iddec <Tagdef>:
|
|
|
434 |
<programlisting>
|
|
|
435 |
<Procdef> ::= Proc <ident> = <Proc_Defn>
|
|
|
436 |
|
|
|
437 |
<Proc_Defn> ::= <Simple_Proc>
|
|
|
438 |
<Proc_Defn> ::= <General_Proc>
|
|
|
439 |
|
|
|
440 |
<Simple_Proc> ::= <Shape> ( <TagShAcc>-List-Opt <VarIntro>-Opt ) <ClosedExp>
|
|
|
441 |
|
|
|
442 |
<TagShAcc> ::= <Parametername> <Access>-Opt : <Shape>
|
|
|
443 |
|
|
|
444 |
<Parametername> ::= <ident>
|
|
|
445 |
|
|
|
446 |
<VarIntro> ::= Varpar <Varparname> : <Alignment>
|
|
|
447 |
|
|
|
448 |
<Varparname> ::= <ident>
|
|
|
449 |
</programlisting>
|
|
|
450 |
<programlisting>
|
|
|
451 |
<General_Proc> ::= General <Shape> ( <For_Callers>; <For_Callees>) <ProcProps>-Opt <ClosedExp>
|
|
|
452 |
|
|
|
453 |
<For_Callers> ::= <TagShAcc>-List-Opt <...>-Opt
|
|
|
454 |
|
|
|
455 |
<For_Callees> ::= <TagShAcc>-List-Opt <...>-Opt
|
|
|
456 |
|
|
|
457 |
<ProcProps> ::= <untidy>-Opt <check_stack>-Opt
|
|
|
458 |
</programlisting>
|
|
|
459 |
A <Procdef> produces a TAGDEF in a tagdef UNIT and and,
|
|
|
460 |
possibly, a TAGDEC in a tagdef UNIT.</para>
|
|
|
461 |
|
|
|
462 |
<para>A <Simple_Proc> produces a make_proc with the obvious
|
|
|
463 |
operands. The scope of the tag names introduced by
|
|
|
464 |
<Parametername> and <Varparname> is the
|
|
|
465 |
<ClosedExp> (see <link linkend="S36">section
|
|
|
466 |
3.3</link>).</para>
|
|
|
467 |
|
|
|
468 |
<para>A <General_Proc> produces a make_general_proc with
|
|
|
469 |
formal caller parameters given by <For_callers> and the
|
|
|
470 |
formal callee parameters given by <For_callees>; in both
|
|
|
471 |
cases the <...> option says that the procedure can be called
|
|
|
472 |
with a variable number of parameters. The scope of the tag names
|
|
|
473 |
are the same as for <Simple_Proc>.</para>
|
|
|
474 |
</sect2>
|
|
|
475 |
</sect1>
|
|
|
476 |
|
|
|
477 |
<sect1 id="S15">
|
|
|
478 |
<title>First-class SORT expansions</title>
|
|
|
479 |
|
|
|
480 |
<para>All of the first-class sorts have similar expansions for native
|
|
|
481 |
TDF constructions and for token applications. I shall take
|
|
|
482 |
<Shape> as the paradigm sort and allow the reader to conjugate
|
|
|
483 |
the following for the the other sorts.</para>
|
|
|
484 |
|
|
|
485 |
<para>Those first-class sorts which include the _cond constructions
|
|
|
486 |
denote them in the same way:
|
|
|
487 |
<programlisting>
|
|
|
488 |
<Shape> ::= SHAPE ? ( <Exp>, <Shape>, <Shape> )
|
|
|
489 |
</programlisting>
|
|
|
490 |
This produces a shape_cond with the obvious parameters.</para>
|
|
|
491 |
|
|
|
492 |
<para>Each constructor for <Shape> with parameters which are
|
|
|
493 |
first-class sorts can be expanded:
|
|
|
494 |
<programlisting>
|
|
|
495 |
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
496 |
</programlisting>
|
|
|
497 |
Each <constructor_param> will be the first_class SORT
|
|
|
498 |
expansion, required by the <shape_constructor> as in the TDF
|
|
|
499 |
specification eg the constructor, pointer, requires a
|
|
|
500 |
<constructor_param> ::= <Alignment>.</para>
|
|
|
501 |
|
|
|
502 |
<para>Any <ident> which is declared to be a
|
|
|
503 |
<shape_token> by a TOKDEF or TOKDEC can be expanded:
|
|
|
504 |
<programlisting>
|
|
|
505 |
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
|
|
|
506 |
</programlisting>
|
|
|
507 |
This will produce a shape_apply_token with the appropriate
|
|
|
508 |
parameters. Each <token_param> will be the first-class SORT
|
|
|
509 |
expansion required by the SORT given by the <TokDecPar> of the
|
|
|
510 |
TOKDEF or TOKDEC which introduced <shape_token>.</para>
|
|
|
511 |
|
|
|
512 |
<sect2 id="S16">
|
|
|
513 |
<title>Access</title>
|
|
|
514 |
|
|
|
515 |
<para>
|
|
|
516 |
<programlisting>
|
|
|
517 |
<Access> ::= ACCESS ? ( <Exp> , <Access> , <Access> )
|
|
|
518 |
<Access> ::= <access_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
519 |
<Access> ::= <access_token> < [ <token_param>-List ] >-Opt
|
|
|
520 |
</programlisting>
|
|
|
521 |
There are no expansions of <Access> other than the standard
|
|
|
522 |
ones.</para>
|
|
|
523 |
</sect2>
|
|
|
524 |
|
|
|
525 |
<sect2 id="S17">
|
|
|
526 |
<title>Al_tag</title>
|
|
|
527 |
|
|
|
528 |
<para>
|
|
|
529 |
<programlisting>
|
|
|
530 |
<Al_tag> ::= <al_tag_token> < [ <token_param>-List ] >-Opt
|
|
|
531 |
</programlisting>
|
|
|
532 |
The standard token expansion.
|
|
|
533 |
<programlisting>
|
|
|
534 |
<Al_tag> ::= <ident>
|
|
|
535 |
</programlisting>
|
|
|
536 |
Any <ident> found as an expansion of <Al_tag> will be
|
|
|
537 |
declared as the name for an AL_TAG.</para>
|
|
|
538 |
</sect2>
|
|
|
539 |
|
|
|
540 |
<sect2 id="S18">
|
|
|
541 |
<title>Alignment</title>
|
|
|
542 |
|
|
|
543 |
<para>
|
|
|
544 |
<programlisting>
|
|
|
545 |
<Alignment> ::= ALIGNMENT ? ( <Exp> , <Alignment> , <Alignment> )
|
|
|
546 |
<Alignment> ::= <alignment_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
547 |
<Alignment> ::= <alignment_token> < [ <token_param>-List ] >-Opt
|
|
|
548 |
</programlisting>
|
|
|
549 |
The standard expansions.
|
|
|
550 |
<programlisting>
|
|
|
551 |
<Alignment> ::= <Al_tag>
|
|
|
552 |
</programlisting>
|
|
|
553 |
This results in an obtain_al_tag of the AL_TAG.
|
|
|
554 |
<programlisting>
|
|
|
555 |
<Alignment> ::= ( <Alignment>-List-Opt )
|
|
|
556 |
</programlisting>
|
|
|
557 |
The <Alignment>s in the <Alignment>-List are united
|
|
|
558 |
using unite_alignments. The empty option results in the top
|
|
|
559 |
ALIGNMENT.</para>
|
|
|
560 |
</sect2>
|
|
|
561 |
|
|
|
562 |
<sect2 id="S19">
|
|
|
563 |
<title>Bitfield_variety</title>
|
|
|
564 |
|
|
|
565 |
<para>
|
|
|
566 |
<programlisting>
|
|
|
567 |
<Bitfield_variety> ::= BITFIELD_VARIETY ? ( <Exp> , <Bitfield_variety>, <Bitfield_variety>)
|
|
|
568 |
<Bitfield_variety> ::= <bitfield_variety_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
569 |
<Bitfield_variety> ::= <bitfield_variety__token> < [ <token_param>-List ] >-Opt
|
|
|
570 |
</programlisting>
|
|
|
571 |
The standard expansions.
|
|
|
572 |
<programlisting>
|
|
|
573 |
<Bitfield_variety> ::= <BfSign>-Opt <Nat>
|
|
|
574 |
<BfSign> ::= <Bool>
|
|
|
575 |
<BfSign> ::= Signed
|
|
|
576 |
<BfSign> ::= Unsigned
|
|
|
577 |
</programlisting>
|
|
|
578 |
This expands to bfvar_bits. The empty default on the sign is
|
|
|
579 |
Signed.</para>
|
|
|
580 |
</sect2>
|
|
|
581 |
|
|
|
582 |
<sect2 id="S20">
|
|
|
583 |
<title>Bool</title>
|
|
|
584 |
|
|
|
585 |
<para>
|
|
|
586 |
<programlisting>
|
|
|
587 |
<Bool> ::= BOOL ? ( <Exp> , <Bool>, <Bool>)
|
|
|
588 |
<Bool> ::= <bool_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
589 |
<Bool> ::= <bool_token> < [ <token_param>-List ] >-Opt
|
|
|
590 |
</programlisting>
|
|
|
591 |
There are no expansions of <Bool> other than the standard
|
|
|
592 |
ones.</para>
|
|
|
593 |
</sect2>
|
|
|
594 |
|
|
|
595 |
<sect2 id="S21">
|
|
|
596 |
<title>Error_treatment</title>
|
|
|
597 |
|
|
|
598 |
<para>
|
|
|
599 |
<programlisting>
|
|
|
600 |
<Error_treatment> ::= ERROR_TREATMENT ?
|
|
|
601 |
( <Exp> , <Error_treatment>, <Error_treatment>)
|
|
|
602 |
<Error_treatment> ::= <error_treatment_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
603 |
<Error_treatment> ::= <error_treatment__token> < [ <token_param>-List ] >-Opt
|
|
|
604 |
</programlisting>
|
|
|
605 |
The standard expansions.
|
|
|
606 |
<programlisting>
|
|
|
607 |
<Error_treatment> ::= <Label>
|
|
|
608 |
</programlisting>
|
|
|
609 |
This gives an error_jump to the label.
|
|
|
610 |
<programlisting>
|
|
|
611 |
<Error_treatment> ::= [ <Error_code>-List]
|
|
|
612 |
<Error_code> ::= overflow
|
|
|
613 |
<Error_code> ::= nil_access
|
|
|
614 |
<Error_code> ::= stack_overflow
|
|
|
615 |
</programlisting>
|
|
|
616 |
Produces trap with the <Error_code>s as arguments.</para>
|
|
|
617 |
</sect2>
|
|
|
618 |
|
|
|
619 |
<sect2 id="S22">
|
|
|
620 |
<title>xp</title>
|
|
|
621 |
|
|
|
622 |
<para>
|
|
|
623 |
<programlisting>
|
|
|
624 |
<Exp> ::= <ExpTerm>
|
|
|
625 |
<Exp> ::= <ExpTerm> <BinaryOp> <ExpTerm>
|
|
|
626 |
</programlisting>
|
|
|
627 |
The <BinaryOp>s include the arithmetic, offset, logical
|
|
|
628 |
operators and assignment and are given in table 1. In this
|
|
|
629 |
expansion, any error_treatments are taken to be wrap.</para>
|
|
|
630 |
|
|
|
631 |
<table frame="all">
|
|
|
632 |
<tgroup cols="4" colsep="1" rowsep="1">
|
|
|
633 |
<thead>
|
|
|
634 |
<row>
|
|
|
635 |
<entry><BinaryOp></entry>
|
|
|
636 |
<entry>TDF constructor</entry>
|
|
|
637 |
<entry><BinaryOp></entry>
|
|
|
638 |
<entry>TDF constructor</entry>
|
|
|
639 |
</row>
|
|
|
640 |
</thead>
|
|
|
641 |
<tbody>
|
|
|
642 |
<row>
|
|
|
643 |
<entry>And</entry>
|
|
|
644 |
<entry>and</entry>
|
|
|
645 |
<entry>Or</entry>
|
|
|
646 |
<entry>or</entry>
|
|
|
647 |
</row>
|
|
|
648 |
<row>
|
|
|
649 |
<entry>Xor</entry>
|
|
|
650 |
<entry>xor</entry>
|
|
|
651 |
<entry>*+.</entry>
|
|
|
652 |
<entry>add_to_ptr</entry>
|
|
|
653 |
</row>
|
|
|
654 |
<row>
|
|
|
655 |
<entry>*-*</entry>
|
|
|
656 |
<entry>subtract_ptrs</entry>
|
|
|
657 |
<entry>.*</entry>
|
|
|
658 |
<entry>offset_mult</entry>
|
|
|
659 |
</row>
|
|
|
660 |
<row>
|
|
|
661 |
<entry>.+.</entry>
|
|
|
662 |
<entry>offset_add</entry>
|
|
|
663 |
<entry>.-.</entry>
|
|
|
664 |
<entry>offset_subtract</entry>
|
|
|
665 |
</row>
|
|
|
666 |
<row>
|
|
|
667 |
<entry>./</entry>
|
|
|
668 |
<entry>offset_div_by_int</entry>
|
|
|
669 |
<entry>./.</entry>
|
|
|
670 |
<entry>offset_div</entry>
|
|
|
671 |
</row>
|
|
|
672 |
<row>
|
|
|
673 |
<entry>.max.</entry>
|
|
|
674 |
<entry>offset_max</entry>
|
|
|
675 |
<entry>%</entry>
|
|
|
676 |
<entry>rem2</entry>
|
|
|
677 |
</row>
|
|
|
678 |
<row>
|
|
|
679 |
<entry>%1</entry>
|
|
|
680 |
<entry>rem1</entry>
|
|
|
681 |
<entry>*</entry>
|
|
|
682 |
<entry>mult</entry>
|
|
|
683 |
</row>
|
|
|
684 |
<row>
|
|
|
685 |
<entry>+</entry>
|
|
|
686 |
<entry>plus</entry>
|
|
|
687 |
<entry>-</entry>
|
|
|
688 |
<entry>minus</entry>
|
|
|
689 |
</row>
|
|
|
690 |
<row>
|
|
|
691 |
<entry>/</entry>
|
|
|
692 |
<entry>div2</entry>
|
|
|
693 |
<entry>/1</entry>
|
|
|
694 |
<entry>div1</entry>
|
|
|
695 |
</row>
|
|
|
696 |
<row>
|
|
|
697 |
<entry><<</entry>
|
|
|
698 |
<entry>shift_left</entry>
|
|
|
699 |
<entry>>></entry>
|
|
|
700 |
<entry>shift_right</entry>
|
|
|
701 |
</row>
|
|
|
702 |
<row>
|
|
|
703 |
<entry>F*</entry>
|
|
|
704 |
<entry>floating_mult</entry>
|
|
|
705 |
<entry>F+</entry>
|
|
|
706 |
<entry>floating_plus</entry>
|
|
|
707 |
</row>
|
|
|
708 |
<row>
|
|
|
709 |
<entry>F-</entry>
|
|
|
710 |
<entry>floating_minus</entry>
|
|
|
711 |
<entry>F/</entry>
|
|
|
712 |
<entry>floating_div</entry>
|
|
|
713 |
</row>
|
|
|
714 |
<row>
|
|
|
715 |
<entry>=</entry>
|
|
|
716 |
<entry>assign</entry>
|
|
|
717 |
</row>
|
|
|
718 |
</tbody>
|
|
|
719 |
</tgroup>
|
|
|
720 |
</table>
|
|
|
721 |
|
|
|
722 |
<para>The names like *+. (i.e. add_to_ptr) do have a certain logic;
|
|
|
723 |
the * indicates that the left operand must be a pointer expression
|
|
|
724 |
and the. that the other is an offset</para>
|
|
|
725 |
|
|
|
726 |
<para>The further expansions of <Exp> are all
|
|
|
727 |
<ExpTerm>s</para>
|
|
|
728 |
|
|
|
729 |
<sect3 id="S23">
|
|
|
730 |
<title>ExpTerm</title>
|
|
|
731 |
|
|
|
732 |
<para>
|
|
|
733 |
<programlisting>
|
|
|
734 |
<ExpTerm> ::= EXP ? ( <Exp> , <Exp>, <Exp>)
|
|
|
735 |
<ExpTerm> ::= <exp_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
736 |
<ExpTerm> ::= <exp_token> < [ <token_param>-List ] >-Opt
|
|
|
737 |
</programlisting>
|
|
|
738 |
The standard expansions.
|
|
|
739 |
<programlisting>
|
|
|
740 |
<ExpTerm> ::= <ClosedExp>
|
|
|
741 |
</programlisting>
|
|
|
742 |
For <ClosedExp>, see <link linkend="S36">section 3.3</link>.
|
|
|
743 |
<programlisting>
|
|
|
744 |
<ExpTerm> ::= ( <Exp> )
|
|
|
745 |
<ExpTerm> ::= - ( <Exp> )
|
|
|
746 |
</programlisting>
|
|
|
747 |
The negate constructor.
|
|
|
748 |
<programlisting>
|
|
|
749 |
<ExpTerm> ::= Sizeof ( <Shape> )
|
|
|
750 |
</programlisting>
|
|
|
751 |
This produces the EXP OFFSET for an index multiplier for arrays of
|
|
|
752 |
<Shape>. It is the shape_offset of <Shape> padded up
|
|
|
753 |
to its alignment.
|
|
|
754 |
<programlisting>
|
|
|
755 |
<ExpTerm> ::= <Tag>
|
|
|
756 |
</programlisting>
|
|
|
757 |
This produces an obtain_tag.
|
|
|
758 |
<programlisting>
|
|
|
759 |
<ExpTerm> ::= * <ident>
|
|
|
760 |
</programlisting>
|
|
|
761 |
The <ident> must have been declared as a variable TAG and
|
|
|
762 |
the construction produces a contents operation with its declared
|
|
|
763 |
SHAPE.
|
|
|
764 |
<programlisting>
|
|
|
765 |
<ExpTerm> ::= * ( <Shape> ) <ExpTerm>
|
|
|
766 |
</programlisting>
|
|
|
767 |
This produces a contents operation with the given <Shape>.
|
|
|
768 |
<programlisting>
|
|
|
769 |
<ExpTerm> ::= <Assertion>
|
|
|
770 |
</programlisting>
|
|
|
771 |
For <Assertion>, see <link linkend="S37">section 3.3.1</link>
|
|
|
772 |
<programlisting>
|
|
|
773 |
<ExpTerm> ::= Case <Exp> ( <RangeDest>-List )
|
|
|
774 |
<RangeDest> ::= <Signed_Nat> < : <Signed_Nat> >-Opt -> <Label>
|
|
|
775 |
</programlisting>
|
|
|
776 |
This produces a case operation.
|
|
|
777 |
<programlisting>
|
|
|
778 |
<ExpTerm> ::= Cons [ <Exp> ] ( < <Offset> : <Exp> >-List )
|
|
|
779 |
<Offset> ::= <Exp>
|
|
|
780 |
</programlisting>
|
|
|
781 |
This produces a make_compound with the [ <Exp> ] as the size
|
|
|
782 |
and fields given by < <Offset> : <Exp> >-List.
|
|
|
783 |
<programlisting>
|
|
|
784 |
<ExpTerm> ::= [ <Variety> ] <ExpTerm>
|
|
|
785 |
</programlisting>
|
|
|
786 |
This produces a change_variety with a wrap error_treatment.
|
|
|
787 |
<programlisting>
|
|
|
788 |
<ExpTerm> ::= <Signed_Nat> ( <Variety> )
|
|
|
789 |
</programlisting>
|
|
|
790 |
This produces a make_int of the <Signed_Nat> with the given
|
|
|
791 |
variety.
|
|
|
792 |
<programlisting>
|
|
|
793 |
<ExpTerm> ::= <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
|
|
|
794 |
<ExpTerm> ::= - <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
|
|
|
795 |
</programlisting>
|
|
|
796 |
Produces a make_floating.
|
|
|
797 |
<programlisting>
|
|
|
798 |
<ExpTerm> ::= <ProcVal> [ <Shape> ] ( <Exp>-List-Opt < Varpar <Exp> >-Opt)
|
|
|
799 |
|
|
|
800 |
<ProcVal> ::= <Tag>
|
|
|
801 |
<ProcVal> ::= ( <Exp> )
|
|
|
802 |
</programlisting>
|
|
|
803 |
Produces an apply_proc with the given parameters returning the
|
|
|
804 |
given <Shape>.
|
|
|
805 |
<programlisting>
|
|
|
806 |
<ExpTerm> ::= <ProcVal> [ <Shape> ]
|
|
|
807 |
[ <Act_Callers>-Opt ; <Act_Callees>-Opt <; <Postlude>>-Opt ]
|
|
|
808 |
<ProcProps>-Opt
|
|
|
809 |
<Act_Callers> ::= <<Exp> <: <ident>>-Opt>-List <...>-Opt
|
|
|
810 |
<Act_Callees> ::= <Exp>-List <...>-Opt
|
|
|
811 |
<Act_Callees> ::= Dynamic ( <Exp> , <Exp> ) <...>-Opt
|
|
|
812 |
<Act_Callees> ::= Same
|
|
|
813 |
<Postlude> ::= <Exp>
|
|
|
814 |
</programlisting>
|
|
|
815 |
Produces an apply_general_proc with the actual caller parameters
|
|
|
816 |
given by <Act_Callers> and the calle parameters given by
|
|
|
817 |
<Act_Callees>; the <...> option indicates that the
|
|
|
818 |
procedure is expecting a variable number of parameters. Any
|
|
|
819 |
<ident>s introduced in <Act_Callers> are in scope in
|
|
|
820 |
<Postlude>.
|
|
|
821 |
<programlisting>
|
|
|
822 |
<Exp> ::= <ProcVal> Tail_call [ <Act_Callees>-Opt ]
|
|
|
823 |
</programlisting>
|
|
|
824 |
Produces a tail_call with the callee parameters given and same
|
|
|
825 |
caller parameters as those of the calling procedure.
|
|
|
826 |
<programlisting>
|
|
|
827 |
<ExpTerm> ::= Proc <Proc_defn>
|
|
|
828 |
</programlisting>
|
|
|
829 |
Produces a make_proc. For <Proc_defn>, see
|
|
|
830 |
<link linkend="S14">section 3.1.7</link> <programlisting>
|
|
|
831 |
<ExpTerm> ::= <String> ( <Variety> )
|
|
|
832 |
</programlisting>
|
|
|
833 |
Produces a make_nof_int of the given variety.
|
|
|
834 |
<programlisting>
|
|
|
835 |
<ExpTerm> ::= # <String>
|
|
|
836 |
</programlisting>
|
|
|
837 |
This produces a TDF fail_installer; this construction is useful
|
|
|
838 |
for narrowing down SHAPE errors detected by the translator.</para>
|
|
|
839 |
</sect3>
|
|
|
840 |
</sect2>
|
|
|
841 |
|
|
|
842 |
<sect2 id="S24">
|
|
|
843 |
<title>Floating_variety</title>
|
|
|
844 |
|
|
|
845 |
<para>
|
|
|
846 |
<programlisting>
|
|
|
847 |
<Floating_variety> ::= FLOATING_VARIETY ?
|
|
|
848 |
( <Exp> , <Floating_variety>, <Floating_variety>)
|
|
|
849 |
<Floating_variety> ::= <floating_variety_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
850 |
<Floating_variety> ::= <floating_variety__token> < [ <token_param>-List ] >-Opt
|
|
|
851 |
</programlisting>
|
|
|
852 |
The standard constructions.
|
|
|
853 |
<programlisting>
|
|
|
854 |
<Floating_variety> ::= Float
|
|
|
855 |
</programlisting>
|
|
|
856 |
An IEEE 32 bit floating variety.
|
|
|
857 |
<programlisting>
|
|
|
858 |
<Floating_variety> ::= Double
|
|
|
859 |
</programlisting>
|
|
|
860 |
An IEEE 64 bit floating variety.</para>
|
|
|
861 |
</sect2>
|
|
|
862 |
|
|
|
863 |
<sect2 id="S25">
|
|
|
864 |
<title>Label</title>
|
|
|
865 |
|
|
|
866 |
<para>
|
|
|
867 |
<programlisting>
|
|
|
868 |
<Label> ::= <label_token> < [ <token_param>-List ] >-Opt
|
|
|
869 |
</programlisting>
|
|
|
870 |
The standard token application.
|
|
|
871 |
<programlisting>
|
|
|
872 |
<Label> ::= <ident>
|
|
|
873 |
</programlisting>
|
|
|
874 |
The <ident> will be declared as a LABEL, whose scope is the
|
|
|
875 |
current procedure.</para>
|
|
|
876 |
</sect2>
|
|
|
877 |
|
|
|
878 |
<sect2 id="S26">
|
|
|
879 |
<title>Nat</title>
|
|
|
880 |
|
|
|
881 |
<para>
|
|
|
882 |
<programlisting>
|
|
|
883 |
<Nat> ::= NAT ? ( <Exp> , <Nat>, <Nat>)
|
|
|
884 |
<Nat> ::= <nat_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
885 |
<Nat> ::= <nat_token> < [ <token_param>-List ] >-Opt
|
|
|
886 |
</programlisting>
|
|
|
887 |
The standard expansions.
|
|
|
888 |
<programlisting>
|
|
|
889 |
<Nat> ::= <integer_denotation>
|
|
|
890 |
</programlisting>
|
|
|
891 |
Produces a make_nat on the integer
|
|
|
892 |
<programlisting>
|
|
|
893 |
<Nat> ::= <character>
|
|
|
894 |
</programlisting>
|
|
|
895 |
Produces a make_nat on the ASCII value of the character.</para>
|
|
|
896 |
</sect2>
|
|
|
897 |
|
|
|
898 |
<sect2 id="S27">
|
|
|
899 |
<title>Ntest</title>
|
|
|
900 |
|
|
|
901 |
<para>
|
|
|
902 |
<programlisting>
|
|
|
903 |
<Ntest> ::= NTEST ? ( <Exp> , <Ntest>, <Ntest>)
|
|
|
904 |
<Ntest> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
905 |
<Ntest> ::= <ntest_token> < [ <token_param>-List ] >-Opt
|
|
|
906 |
</programlisting>
|
|
|
907 |
The standard expansions.
|
|
|
908 |
<programlisting>
|
|
|
909 |
<Ntest> ::= !<
|
|
|
910 |
</programlisting>
|
|
|
911 |
Produces not_less_than.
|
|
|
912 |
<programlisting>
|
|
|
913 |
<Ntest> ::= !<=
|
|
|
914 |
</programlisting>
|
|
|
915 |
Produces not_less_than_or_equal.
|
|
|
916 |
<programlisting>
|
|
|
917 |
<Ntest> ::= !=
|
|
|
918 |
</programlisting>
|
|
|
919 |
Produces not_equal.
|
|
|
920 |
<programlisting>
|
|
|
921 |
<Ntest> ::= !>
|
|
|
922 |
</programlisting>
|
|
|
923 |
Produces not_greater_than.
|
|
|
924 |
<programlisting>
|
|
|
925 |
<Ntest> ::= !>=
|
|
|
926 |
</programlisting>
|
|
|
927 |
Produces not_greater_than_or_equal.
|
|
|
928 |
<programlisting>
|
|
|
929 |
<Ntest> ::= !Comparable
|
|
|
930 |
</programlisting>
|
|
|
931 |
Produces not_comparable.
|
|
|
932 |
<programlisting>
|
|
|
933 |
<Ntest> ::= <
|
|
|
934 |
</programlisting>
|
|
|
935 |
Produces less_than.
|
|
|
936 |
<programlisting>
|
|
|
937 |
<Ntest> ::= <=
|
|
|
938 |
</programlisting>
|
|
|
939 |
Produces less_than_or_equal.
|
|
|
940 |
<programlisting>
|
|
|
941 |
<Ntest> ::= ==
|
|
|
942 |
</programlisting>
|
|
|
943 |
Produces equal.
|
|
|
944 |
<programlisting>
|
|
|
945 |
<Ntest> ::= >
|
|
|
946 |
</programlisting>
|
|
|
947 |
Produces greater_than.
|
|
|
948 |
<programlisting>
|
|
|
949 |
<Ntest> ::= >=
|
|
|
950 |
</programlisting>
|
|
|
951 |
Produces greater_than_or_equal.</para>
|
|
|
952 |
</sect2>
|
|
|
953 |
|
|
|
954 |
<sect2 id="S28">
|
|
|
955 |
<title>Rounding_mode</title>
|
|
|
956 |
|
|
|
957 |
<para>
|
|
|
958 |
<programlisting>
|
|
|
959 |
<Rounding_mode> ::= ROUNDING_MODE?
|
|
|
960 |
( <Exp> , <Rounding_mode>, <Rounding_mode>)
|
|
|
961 |
<Rounding_mode> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
962 |
<Rounding_mode> ::= <ntest_token> < [ <token_param>-List ] >-Opt
|
|
|
963 |
</programlisting>
|
|
|
964 |
There are no constructions for <Rounding_mode> other than
|
|
|
965 |
the standard ones.</para>
|
|
|
966 |
</sect2>
|
|
|
967 |
|
|
|
968 |
<sect2 id="S29">
|
|
|
969 |
<title>Shape</title>
|
|
|
970 |
|
|
|
971 |
<para>
|
|
|
972 |
<programlisting>
|
|
|
973 |
<Shape> ::= SHAPE ? ( <Exp> , <Shape>, <Shape>)
|
|
|
974 |
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
975 |
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
|
|
|
976 |
</programlisting>
|
|
|
977 |
The standard expansions.
|
|
|
978 |
<programlisting>
|
|
|
979 |
<Shape> ::= Float
|
|
|
980 |
</programlisting>
|
|
|
981 |
The shape for an IEEE 32 bit float.
|
|
|
982 |
<programlisting>
|
|
|
983 |
<Shape> ::= Double
|
|
|
984 |
</programlisting>
|
|
|
985 |
The shape for an IEEE 64 bit float.
|
|
|
986 |
<programlisting>
|
|
|
987 |
<Shape> ::= <Sign>-Opt Int
|
|
|
988 |
<Sign> ::= Signed
|
|
|
989 |
<Sign> ::= Unsigned
|
|
|
990 |
</programlisting>
|
|
|
991 |
The shape for a 32 bit signed or unsigned integer. The default is
|
|
|
992 |
signed.
|
|
|
993 |
<programlisting>
|
|
|
994 |
<Shape> ::= <Sign>-Opt Long
|
|
|
995 |
</programlisting>
|
|
|
996 |
The shape for a 32 bit signed or unsigned integer.
|
|
|
997 |
<programlisting>
|
|
|
998 |
<Shape> ::= <Sign>-Opt Short
|
|
|
999 |
</programlisting>
|
|
|
1000 |
The shape for a 16 bit signed or unsigned integer.
|
|
|
1001 |
<programlisting>
|
|
|
1002 |
<Shape> ::= <Sign>-Opt Char
|
|
|
1003 |
</programlisting>
|
|
|
1004 |
The shape for a 8 bit signed or unsigned integer.
|
|
|
1005 |
<programlisting>
|
|
|
1006 |
<Shape> ::= Ptr <Shape>
|
|
|
1007 |
</programlisting>
|
|
|
1008 |
The SHAPE pointer(alignment(<Shape>)).</para>
|
|
|
1009 |
</sect2>
|
|
|
1010 |
|
|
|
1011 |
<sect2 id="S30">
|
|
|
1012 |
<title>Signed_Nat</title>
|
|
|
1013 |
|
|
|
1014 |
<para>
|
|
|
1015 |
<programlisting>
|
|
|
1016 |
<Signed_Nat> ::= SIGNED_NAT ? ( <Exp> , <Signed_Nat>, <Signed_Nat>)
|
|
|
1017 |
<Signed_Nat> ::= <signed_nat_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
1018 |
<Signed_Nat> ::= <signed_nat_token> < [ <token_param>-List ] >-Opt
|
|
|
1019 |
</programlisting>
|
|
|
1020 |
The standard expansions.
|
|
|
1021 |
<programlisting>
|
|
|
1022 |
<Signed_Nat> ::= <integer_denotation>
|
|
|
1023 |
<Signed_Nat> ::= - <integer_denotation>
|
|
|
1024 |
</programlisting>
|
|
|
1025 |
This produces a make_signed_nat on the integer value.
|
|
|
1026 |
<programlisting>
|
|
|
1027 |
<Signed_Nat> ::= <character>
|
|
|
1028 |
<Signed_Nat> ::= - <character>
|
|
|
1029 |
</programlisting>
|
|
|
1030 |
This produces a make_signed_nat on the ASCII value of the
|
|
|
1031 |
character.
|
|
|
1032 |
<programlisting>
|
|
|
1033 |
<Signed_Nat> ::= LINE
|
|
|
1034 |
</programlisting>
|
|
|
1035 |
This produces a make_signed_nat on the current line number of the
|
|
|
1036 |
file being compiled - useful for writing test programs.
|
|
|
1037 |
<programlisting>
|
|
|
1038 |
<Signed_Nat> ::= + <Nat>
|
|
|
1039 |
<Signed_Nat> ::= - <Nat>
|
|
|
1040 |
</programlisting>
|
|
|
1041 |
This produces an appropriately signed <Signed_Nat> from a
|
|
|
1042 |
<Nat>.</para>
|
|
|
1043 |
</sect2>
|
|
|
1044 |
|
|
|
1045 |
<sect2 id="S31">
|
|
|
1046 |
<title>String</title>
|
|
|
1047 |
|
|
|
1048 |
<para>
|
|
|
1049 |
<programlisting>
|
|
|
1050 |
<String> ::= STRING? ( <Exp> , <String>, <String>)
|
|
|
1051 |
<String> ::= <string_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
1052 |
<String> ::= <string_token> < [ <token_param>-List ] >-Opt
|
|
|
1053 |
</programlisting>
|
|
|
1054 |
The standard expansions
|
|
|
1055 |
<programlisting>
|
|
|
1056 |
<String> ::= <string>
|
|
|
1057 |
</programlisting>
|
|
|
1058 |
Produces a make_string.</para>
|
|
|
1059 |
</sect2>
|
|
|
1060 |
|
|
|
1061 |
<sect2 id="S32">
|
|
|
1062 |
<title>Tag</title>
|
|
|
1063 |
<para>
|
|
|
1064 |
<programlisting>
|
|
|
1065 |
<Tag> ::= <tag_token> < [ <token_param>-List ] >-Opt
|
|
|
1066 |
</programlisting>
|
|
|
1067 |
The standard token application.
|
|
|
1068 |
<programlisting>
|
|
|
1069 |
<Tag> ::= <ident>
|
|
|
1070 |
</programlisting>
|
|
|
1071 |
This gives an obtain_tag; the <ident> must been declared as
|
|
|
1072 |
a TAG either globally or locally.</para>
|
|
|
1073 |
</sect2>
|
|
|
1074 |
|
|
|
1075 |
<sect2 id="S33">
|
|
|
1076 |
<title>Token</title>
|
|
|
1077 |
|
|
|
1078 |
<para>TOKEN is rather a limited first-class sort. There is no
|
|
|
1079 |
explicit construction given for token_apply_token, since the only
|
|
|
1080 |
place where it can occur is in an expansion of a token parameter
|
|
|
1081 |
of another token; here it is produced implicitly. The only place
|
|
|
1082 |
where <Token> is expanded is in an actual TOKEN parameter of
|
|
|
1083 |
a token application; other uses (e.g. as in <shape_token>)
|
|
|
1084 |
are always <ident>s.
|
|
|
1085 |
<programlisting>
|
|
|
1086 |
<Token> ::= <ident>
|
|
|
1087 |
</programlisting>
|
|
|
1088 |
The <ident> must have been declarered by a <Tokdec> or
|
|
|
1089 |
<Tokdec> or is a formal parameter of TOKEN.
|
|
|
1090 |
<programlisting>
|
|
|
1091 |
<Token> ::= Use <Tok_Defn>
|
|
|
1092 |
</programlisting>
|
|
|
1093 |
This produces a use_tokdef. For <Tok_Defn> see
|
|
|
1094 |
<link linkend="S9">section 3.1.2</link>. The critical use of this
|
|
|
1095 |
construction is to provide an actual TOKEN parameter to a token
|
|
|
1096 |
application where the <Tok_Defn> contains uses of tags or
|
|
|
1097 |
labels local to a procedure.</para>
|
|
|
1098 |
</sect2>
|
|
|
1099 |
|
|
|
1100 |
<sect2 id="S34">
|
|
|
1101 |
<title>Transfer_mode</title>
|
|
|
1102 |
<para>
|
|
|
1103 |
<programlisting>
|
|
|
1104 |
<Transfer_mode> ::= TRANSFER_MODE ? ( <Exp> , <Transfer_mode>, <Transfer_mode>)
|
|
|
1105 |
<Transfer_mode> ::= <transfer_mode_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
1106 |
<Transfer_mode> ::= <transfer_mode_token> < [ <token_param>-List ] >-Opt
|
|
|
1107 |
</programlisting>
|
|
|
1108 |
There are no expansions for <Transfer_mode> other than the
|
|
|
1109 |
standard expansions.</para>
|
|
|
1110 |
</sect2>
|
|
|
1111 |
|
|
|
1112 |
<sect2 id="S35">
|
|
|
1113 |
<title>Variety</title>
|
|
|
1114 |
<para>
|
|
|
1115 |
<programlisting>
|
|
|
1116 |
<Variety> ::= VARIETY ? ( <Exp> , <Variety>, <Variety>)
|
|
|
1117 |
<Variety> ::= <variety_constructor> < ( <constructor_param>-List ) >-Opt
|
|
|
1118 |
<Variety> ::= <variety_token> < [ <token_param>-List ] >-Opt
|
|
|
1119 |
</programlisting>
|
|
|
1120 |
The standard expansions.
|
|
|
1121 |
<programlisting>
|
|
|
1122 |
<Variety> ::= <Signed_Nat> : <Signed_Nat>
|
|
|
1123 |
</programlisting>
|
|
|
1124 |
This produces var_limits.
|
|
|
1125 |
<programlisting>
|
|
|
1126 |
<Variety> ::= <Sign>-Opt Int
|
|
|
1127 |
<Variety> ::= <Sign>-Opt Long
|
|
|
1128 |
<Variety> ::= <Sign>-Opt Short
|
|
|
1129 |
<Variety> ::= <Sign>-Opt Char
|
|
|
1130 |
</programlisting>
|
|
|
1131 |
This produces the variety of the appropriate integer shape.</para>
|
|
|
1132 |
</sect2>
|
|
|
1133 |
</sect1>
|
|
|
1134 |
|
|
|
1135 |
<sect1 id="S36">
|
|
|
1136 |
<title>Control structure and local declarations</title>
|
|
|
1137 |
|
|
|
1138 |
<para>The control and declaration structure is given by
|
|
|
1139 |
<ClosedExp>:
|
|
|
1140 |
<programlisting>
|
|
|
1141 |
<ClosedExp> ::= { <ExpSeq> }
|
|
|
1142 |
|
|
|
1143 |
<ExpSeq> ::= <Exp>-Opt
|
|
|
1144 |
<ExpSeq> ::= <ExpSeq> ; <Exp>-Opt
|
|
|
1145 |
</programlisting>
|
|
|
1146 |
This produces a TDF sequence if there is more than one
|
|
|
1147 |
<Exp>-Opt; if there is only one it is simply the production
|
|
|
1148 |
for <Exp>-Opt; any empty <Exp>-Opt produce make_top.
|
|
|
1149 |
<programlisting>
|
|
|
1150 |
<ClosedExp> ::= <ConditionalExp>
|
|
|
1151 |
<ClosedExp> ::= <RepeatExp>
|
|
|
1152 |
<ClosedExp> ::= <LabelledExp>
|
|
|
1153 |
<ClosedExp> ::= <Local_Defn>
|
|
|
1154 |
</programlisting>
|
|
|
1155 |
The effect of these, together with the expansion of
|
|
|
1156 |
<Assertion> is given below.</para>
|
|
|
1157 |
|
|
|
1158 |
<sect2 id="S37">
|
|
|
1159 |
<title>ConditionalExp and Assertion</title>
|
|
|
1160 |
|
|
|
1161 |
<para>
|
|
|
1162 |
<programlisting>
|
|
|
1163 |
<ConditionalExp> ::= ? { <ExpSeq> | <LabelSetting>-Opt <ExpSeq> }
|
|
|
1164 |
|
|
|
1165 |
<LabelSetting> ::= : <Label> :
|
|
|
1166 |
</programlisting>
|
|
|
1167 |
This produces a TDF conditional. The scope of a LABEL
|
|
|
1168 |
<ident> which may be introduced by <Label> is the
|
|
|
1169 |
first <ExpSeq>. A branch to the second half of the
|
|
|
1170 |
conditional will usually be made by the failure of an
|
|
|
1171 |
<Assertion> ( ie a TDF _test) in the first half.
|
|
|
1172 |
<programlisting>
|
|
|
1173 |
<Assertion> ::= <Query> ( <Exp> <Ntest> <Exp> <FailDest>-Opt )
|
|
|
1174 |
|
|
|
1175 |
<Query> ::= ?
|
|
|
1176 |
</programlisting>
|
|
|
1177 |
The assertion will be translated as an integer_test
|
|
|
1178 |
<programlisting>
|
|
|
1179 |
<Query> ::= F?
|
|
|
1180 |
</programlisting>
|
|
|
1181 |
The assertion will be translated as a floating_test with a wrap
|
|
|
1182 |
error_treatment.
|
|
|
1183 |
<programlisting>
|
|
|
1184 |
<Query> ::= *?
|
|
|
1185 |
</programlisting>
|
|
|
1186 |
The assertion will be translated as a pointer_test.
|
|
|
1187 |
<programlisting>
|
|
|
1188 |
<Query> ::=.?
|
|
|
1189 |
</programlisting>
|
|
|
1190 |
The assertion will be translated as an offset_test.
|
|
|
1191 |
<programlisting>
|
|
|
1192 |
<Query> ::= P?
|
|
|
1193 |
</programlisting>
|
|
|
1194 |
The assertion will be translated as a proc_test.
|
|
|
1195 |
<programlisting>
|
|
|
1196 |
<FailDest> ::= | <Label>
|
|
|
1197 |
|
|
|
1198 |
</programlisting>
|
|
|
1199 |
The <Assertion> will produce the appropriate _test on its
|
|
|
1200 |
component <Exp>s. If the test fails, then control will pass
|
|
|
1201 |
to the <FailDest>-Opt. If <FailDest>-Opt is not empty,
|
|
|
1202 |
this is the <Label>. Otherwise, the <Assertion> must
|
|
|
1203 |
be in the immediate context of a <ConditionalExp> or
|
|
|
1204 |
<RepeatExp> with an empty <LabelSetting>-Opt; in which
|
|
|
1205 |
case this is treated as an anonymous label and control passes to
|
|
|
1206 |
there. For example, the following <Conditional> delivers the
|
|
|
1207 |
maximum of two integers:
|
|
|
1208 |
<programlisting>
|
|
|
1209 |
?{ ?(a >= b); a | b }
|
|
|
1210 |
</programlisting>
|
|
|
1211 |
This is equivalent to:
|
|
|
1212 |
<programlisting>
|
|
|
1213 |
?{ ?(a >= b | L ); a | :L: b }
|
|
|
1214 |
</programlisting>
|
|
|
1215 |
without the hassle of having to invent the LABEL name, L.</para>
|
|
|
1216 |
</sect2>
|
|
|
1217 |
|
|
|
1218 |
<sect2 id="S38">
|
|
|
1219 |
<title>RepeatExp</title>
|
|
|
1220 |
|
|
|
1221 |
<para>
|
|
|
1222 |
<programlisting>
|
|
|
1223 |
<RepeatExp> ::= Rep <Starter>-Opt { <LabelSetting>-Opt <ExpSeq> }
|
|
|
1224 |
|
|
|
1225 |
<Starter> = ( <ExpSeq> )
|
|
|
1226 |
</programlisting>
|
|
|
1227 |
This produces a TDF repeat. The loop will usually repeat by an
|
|
|
1228 |
<Assertion> failing to the <LabelSetting>-Opt; an
|
|
|
1229 |
empty <LabelSetting>-Opt will follow the same conventions as
|
|
|
1230 |
one in a <Conditional>. An empty <Starter>-Opt will
|
|
|
1231 |
produce make_top.</para>
|
|
|
1232 |
</sect2>
|
|
|
1233 |
|
|
|
1234 |
<sect2 id="S39">
|
|
|
1235 |
<title>LabelledExp</title>
|
|
|
1236 |
|
|
|
1237 |
<para>
|
|
|
1238 |
<programlisting>
|
|
|
1239 |
<LabelledExp> ::= Labelled { <ExpSeq> <Places> }
|
|
|
1240 |
|
|
|
1241 |
<Places> ::= <Place>
|
|
|
1242 |
<Places> ::= <Places> <Place>
|
|
|
1243 |
|
|
|
1244 |
<Place> ::= | : <Label> : <ExpSeq>
|
|
|
1245 |
</programlisting>
|
|
|
1246 |
This produces a TDF labelled with the obvious parameters. The
|
|
|
1247 |
scope of any LABEL <idents> introduced by the <Label>s
|
|
|
1248 |
is the <LabelledExp>.</para>
|
|
|
1249 |
</sect2>
|
|
|
1250 |
|
|
|
1251 |
<sect2 id="S40">
|
|
|
1252 |
<title>Local_Defn</title>
|
|
|
1253 |
|
|
|
1254 |
<para>A <Local_Defn> introduces an <ident> as a TAG for
|
|
|
1255 |
the scope of the component <ClosedExp>. Any containing an
|
|
|
1256 |
<Access> visible is also available globally - however it
|
|
|
1257 |
will only make sense in the constructor env_offset.
|
|
|
1258 |
<programlisting>
|
|
|
1259 |
<Local_Defn> ::= Var <ident> <Access>-Opt <VarInit> <ClosedExp>
|
|
|
1260 |
|
|
|
1261 |
<VarInit> ::= = <Exp>
|
|
|
1262 |
</programlisting>
|
|
|
1263 |
This <Local_Defn> produces a TDF variable with the obvious
|
|
|
1264 |
parameters.
|
|
|
1265 |
<programlisting>
|
|
|
1266 |
<Local_Defn> ::= Var <ident> <Access>-Opt : <Shape> <VarInit>-Opt <ClosedExp>
|
|
|
1267 |
</programlisting>
|
|
|
1268 |
Also a TDF variable. An empty <VarInit>-Opt gives
|
|
|
1269 |
make_value(<Shape>) as the initialisation to the variable.
|
|
|
1270 |
Using this form of variable definition also has the advantage of
|
|
|
1271 |
allowing one to use the simple form of the contents operation (*
|
|
|
1272 |
in <link linkend="S22">section 3.2.7</link>).
|
|
|
1273 |
<programlisting>
|
|
|
1274 |
<Local_Defn> ::= Let <ident> <Access>-Opt = <Exp> <ClosedExp>
|
|
|
1275 |
</programlisting>
|
|
|
1276 |
This produces a TDF identify with the obvious parameters.</para>
|
|
|
1277 |
</sect2>
|
|
|
1278 |
</sect1>
|
|
|
1279 |
</chapter>
|
|
|
1280 |
|
|
|
1281 |
<chapter id="S41">
|
|
|
1282 |
<title>Example PL_TDF programs</title>
|
|
|
1283 |
|
|
|
1284 |
<sect1 id="S42">
|
|
|
1285 |
<title>Sieve of Erastothenes</title>
|
|
|
1286 |
|
|
|
1287 |
<para>
|
|
|
1288 |
<programlisting>
|
|
|
1289 |
/* Print out the primes less than 10000 */
|
|
|
1290 |
String s1 = "%d\t"; /* good strings for printf */
|
|
|
1291 |
String s2 = "\n";
|
|
|
1292 |
|
|
|
1293 |
Var n: nof(10000, Char); /* will contain1 for prime; 0 for composite */
|
|
|
1294 |
|
|
|
1295 |
Tokdef N = [ind:EXP]EXP n *+. (Sizeof(Char) .* ind);
|
|
|
1296 |
/* Token delivering pointer to element of n */
|
|
|
1297 |
|
|
|
1298 |
Iddec printf : proc; /* definition provided by ansi library */
|
|
|
1299 |
|
|
|
1300 |
Proc main = top ()
|
|
|
1301 |
Var i:Int
|
|
|
1302 |
Var j:Int
|
|
|
1303 |
{ Rep (i = 2(Int))
|
|
|
1304 |
{ /* set i-th element of n to 1 */
|
|
|
1305 |
N[* i] = 1(Char);
|
|
|
1306 |
i = (* i + 1(Int));
|
|
|
1307 |
?(* i >= 10000(Int)) /* NB assertion fails to continue loop */
|
|
|
1308 |
}
|
|
|
1309 |
Rep (i = 2(Int) )
|
|
|
1310 |
{
|
|
|
1311 |
?{ ?( *(Char)N[* i] == 1(Char));
|
|
|
1312 |
/* if its a prime ... */
|
|
|
1313 |
Rep ( j = (* i + * i) )
|
|
|
1314 |
{ /*... wipe out composites */
|
|
|
1315 |
N[* j] = 0(Char);
|
|
|
1316 |
j = (* j + * i);
|
|
|
1317 |
?(* j >= 10000(Int))
|
|
|
1318 |
}
|
|
|
1319 |
| make_top
|
|
|
1320 |
};
|
|
|
1321 |
i = (* i + 1(Int));
|
|
|
1322 |
?(* i >= 100(Int))
|
|
|
1323 |
};
|
|
|
1324 |
Rep (i = 2(Int); j = 0(Int) )
|
|
|
1325 |
{ ?{ ?( *(Char)N[* i] == 1(Char));
|
|
|
1326 |
/* if it's a prime, print it */
|
|
|
1327 |
printf[top](s1, * i);
|
|
|
1328 |
j = (* j + 1(Int));
|
|
|
1329 |
?{ ?( * j == 5(Int));
|
|
|
1330 |
/* print new line */
|
|
|
1331 |
printf[top](s2);
|
|
|
1332 |
j = 0(Int)
|
|
|
1333 |
| make_top
|
|
|
1334 |
}
|
|
|
1335 |
| make_top
|
|
|
1336 |
};
|
|
|
1337 |
i = (* i + 1(Int));
|
|
|
1338 |
?(* i >= 10000(Int))
|
|
|
1339 |
};
|
|
|
1340 |
return(make_top)
|
|
|
1341 |
};
|
|
|
1342 |
|
|
|
1343 |
Keep (main) /* main will be an external name; so will printf since it is not defined */
|
|
|
1344 |
</programlisting>
|
|
|
1345 |
</para>
|
|
|
1346 |
</sect1>
|
|
|
1347 |
|
|
|
1348 |
<sect1 id="S43">
|
|
|
1349 |
<title>Example with structures</title>
|
|
|
1350 |
|
|
|
1351 |
<para>
|
|
|
1352 |
<programlisting>
|
|
|
1353 |
Struct C (re:Double, im:Double);
|
|
|
1354 |
/* define TOKENs : C as a SHAPE for complex, with field offsets .re and .im
|
|
|
1355 |
and selectors re and im */
|
|
|
1356 |
|
|
|
1357 |
Iddec printf:proc;
|
|
|
1358 |
|
|
|
1359 |
Proc addC = C (lv:C, rv:C) /* add two complex numbers */
|
|
|
1360 |
Let l = * lv
|
|
|
1361 |
Let r = * rv
|
|
|
1362 |
{ return( Cons[shape_offset(C)] ( .re: re[l] F+ re[r], .im: im[l] F+ im[r]) ) } ;
|
|
|
1363 |
|
|
|
1364 |
String s1 = "Ans = (%g, %g)\n";
|
|
|
1365 |
|
|
|
1366 |
Proc main = top()
|
|
|
1367 |
Let x = Cons[shape_offset(C)] (.re: 1.0(Double), .im:2.0(Double))
|
|
|
1368 |
Let y = Cons[shape_offset(C)] (.re: 3.0(Double), .im:4.0(Double))
|
|
|
1369 |
Let z = addC[C](x,y)
|
|
|
1370 |
{ printf[top](s1, re[z], im[z]);
|
|
|
1371 |
/* prints out "Ans = (4, 6)" */
|
|
|
1372 |
return(make_top)
|
|
|
1373 |
};
|
|
|
1374 |
|
|
|
1375 |
Keep(main)
|
|
|
1376 |
</programlisting>
|
|
|
1377 |
</para>
|
|
|
1378 |
</sect1>
|
|
|
1379 |
|
|
|
1380 |
<sect1 id="S44">
|
|
|
1381 |
<title>Test for case</title>
|
|
|
1382 |
|
|
|
1383 |
<para>
|
|
|
1384 |
<programlisting>
|
|
|
1385 |
Iddec printf:proc;
|
|
|
1386 |
|
|
|
1387 |
String s1 = "%d is not in [%d,%d]\n";
|
|
|
1388 |
String s2 = "%d OK\n";
|
|
|
1389 |
|
|
|
1390 |
Proc test = top(i:Int, l:Int, u:Int) /* report whether l<=i<=u */
|
|
|
1391 |
?{ ?(* i >= * l); ?(* i <= * u);
|
|
|
1392 |
printf[top](s2, * i);
|
|
|
1393 |
return(make_top)
|
|
|
1394 |
| printf[top](s1, * i, * l, * u);
|
|
|
1395 |
return(make_top)
|
|
|
1396 |
};
|
|
|
1397 |
|
|
|
1398 |
String s3 = "ERROR with %d\n";
|
|
|
1399 |
|
|
|
1400 |
Proc main = top() /* check to see that case is working */
|
|
|
1401 |
Var i:Int = 0(Int)
|
|
|
1402 |
Rep {
|
|
|
1403 |
Labelled {
|
|
|
1404 |
Case * i (0 -> l0, 1 -> l1, 2:3 -> l2, 4:10000 -> l3)
|
|
|
1405 |
| :l0: test[top](* i, 0(Int), 0(Int))
|
|
|
1406 |
| :l1: test[top](* i, 1(Int), 1(Int))
|
|
|
1407 |
| :l2: test[top](* i, 2(Int), 3(Int))
|
|
|
1408 |
| :l3: printf[top](s3, * i)
|
|
|
1409 |
};
|
|
|
1410 |
i = (* i + 1(Int));
|
|
|
1411 |
?(* i > 3(Int));
|
|
|
1412 |
return(make_top)
|
|
|
1413 |
};
|
|
|
1414 |
|
|
|
1415 |
Keep (main, test)
|
|
|
1416 |
</programlisting>
|
|
|
1417 |
</para>
|
|
|
1418 |
</sect1>
|
|
|
1419 |
|
|
|
1420 |
<sect1 id="S45">
|
|
|
1421 |
<title>Example of use of high-order TOKENs</title>
|
|
|
1422 |
|
|
|
1423 |
<para>
|
|
|
1424 |
<programlisting>
|
|
|
1425 |
Tokdef IF = [ boolexp:TOKEN[LABEL]EXP, thenpt:EXP, elsept:EXP] EXP
|
|
|
1426 |
?{ boolexp[lab]; thenpt | :lab: elsept };
|
|
|
1427 |
/* IF is a TOKEN which can be used to mirror a standard if ... then ... else
|
|
|
1428 |
construction; the boolexp is a formal TOKEN with a LABEL parameter
|
|
|
1429 |
which is jumped to if the boolean is false */
|
|
|
1430 |
|
|
|
1431 |
Iddec printf: proc;
|
|
|
1432 |
|
|
|
1433 |
String cs = "Correct\n";
|
|
|
1434 |
String ws = "Wrong\n";
|
|
|
1435 |
|
|
|
1436 |
Proc main = top()
|
|
|
1437 |
Var i:Int = 0(Int)
|
|
|
1438 |
{
|
|
|
1439 |
IF[ Use [l:LABEL]EXP ?(* i == 0(Int) | l), printf[top](cs), printf[top](ws) ];
|
|
|
1440 |
/* in other words if (i==0) printf("Correct") else printf("Wrong") */
|
|
|
1441 |
IF[ Use [l:LABEL]EXP ?(* i != 0(Int) | l), printf[top](ws), printf[top](cs) ];
|
|
|
1442 |
i = IF[ Use [l:LABEL]EXP ?(* i != 0(Int) | l), 2(Int), 3(Int)];
|
|
|
1443 |
IF[ Use [l:LABEL]EXP ?(* i == 3(Int) | l), printf[top](cs), printf[top](ws) ];
|
|
|
1444 |
return(make_top)
|
|
|
1445 |
};
|
|
|
1446 |
|
|
|
1447 |
Keep (main)
|
|
|
1448 |
</programlisting>
|
|
|
1449 |
</para>
|
|
|
1450 |
</sect1>
|
|
|
1451 |
|
|
|
1452 |
<sect1 id="S46">
|
|
|
1453 |
<title>A test for long jumps</title>
|
|
|
1454 |
|
|
|
1455 |
<para>
|
|
|
1456 |
<programlisting>
|
|
|
1457 |
Iddec printf:proc;
|
|
|
1458 |
|
|
|
1459 |
Proc f = bottom(env:pointer(frame_alignment), lab:pointer(code_alignment) )
|
|
|
1460 |
{
|
|
|
1461 |
long_jump(* env, * lab)
|
|
|
1462 |
};
|
|
|
1463 |
|
|
|
1464 |
String s1 = "Should not reach here\n";
|
|
|
1465 |
String s2 = "long-jump OK\n";
|
|
|
1466 |
|
|
|
1467 |
Proc main = top()
|
|
|
1468 |
Labelled{
|
|
|
1469 |
f[bottom](current_env, make_local_lv(l));
|
|
|
1470 |
printf[top](s1); /* should never reach here */
|
|
|
1471 |
return(make_top)
|
|
|
1472 |
| :l:
|
|
|
1473 |
printf[top](s2);
|
|
|
1474 |
return(make_top)
|
|
|
1475 |
};
|
|
|
1476 |
|
|
|
1477 |
Keep (main)
|
|
|
1478 |
</programlisting>
|
|
|
1479 |
</para>
|
|
|
1480 |
</sect1>
|
|
|
1481 |
</chapter>
|
|
|
1482 |
|
|
|
1483 |
<chapter>
|
|
|
1484 |
<title>Use of the PL_TDF compiler</title>
|
|
|
1485 |
|
|
|
1486 |
<para>Conventionally, PL_TDF programs are held in normal text files with
|
|
|
1487 |
suffix .pl. The PL_TDF compiler is invoked by:
|
|
|
1488 |
<programlisting>
|
|
|
1489 |
pl [-v] [-Iinclude_path ...] [-g] [-V ] infile.pl outfile.j
|
|
|
1490 |
</programlisting>
|
|
|
1491 |
This compiles infile.pl to TDF in outfile.j. This file can be linked and
|
|
|
1492 |
loaded just as any other .j file using tcc.</para>
|
|
|
1493 |
|
|
|
1494 |
<para>The -v option will produce a cut-down pretty print of the TDF for
|
|
|
1495 |
the definitions and declarations of the tags, tokens and al_tags of
|
|
|
1496 |
the program on the standard output.</para>
|
|
|
1497 |
|
|
|
1498 |
<para>The -I options will defines the paths for any #include
|
|
|
1499 |
pre-processing directives in the text.</para>
|
|
|
1500 |
|
|
|
1501 |
<para>The -g option will put line number information into the
|
|
|
1502 |
TDF.</para>
|
|
|
1503 |
|
|
|
1504 |
<para>The -V option will print version information of both pl and the
|
|
|
1505 |
TDF it produces.</para>
|
|
|
1506 |
|
|
|
1507 |
<para>Compile-time error reporting is rather rudimentary and error
|
|
|
1508 |
recovery non-existent. Only the first error found will be reported on
|
|
|
1509 |
the standard error channel. This will give some indication of the type
|
|
|
1510 |
of error, together with the text line number and a print-out of the
|
|
|
1511 |
line, marking the place within the line where the error was
|
|
|
1512 |
detected.</para>
|
|
|
1513 |
|
|
|
1514 |
<para>Errors which can only be detected at translate-time are much more
|
|
|
1515 |
difficult to correct. These are usually shape or alignment errors,
|
|
|
1516 |
particularly in the construction of offsets. Try compiling and
|
|
|
1517 |
translating with the -g option. On the error, the translator will
|
|
|
1518 |
output the source filename and an approximate line-number
|
|
|
1519 |
corresponding to the position of the error in the PL_TDF.</para>
|
|
|
1520 |
|
|
|
1521 |
<para>Translating with the -g option may sometimes give warning messages
|
|
|
1522 |
from the system assembler being used; some assemblers object to being
|
|
|
1523 |
given line number information in anything else but the .text segment
|
|
|
1524 |
of the program. The main intention of the -g option is to detect and
|
|
|
1525 |
correct errors errors thrown up by the translators and not for
|
|
|
1526 |
run-time de-bugging, so do not regard a warning like this as a bug in
|
|
|
1527 |
the system.</para>
|
|
|
1528 |
</chapter>
|
|
|
1529 |
</book>
|