| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>Specification of TDF Constructs</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<H1>TDF Specification, Issue 4.0</H1>
|
|
|
8 |
<H3>January 1998</H3>
|
|
|
9 |
<A HREF="spec9.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
|
|
|
10 |
<A HREF="spec7.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
11 |
<A HREF="spec1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
12 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
13 |
</A>
|
|
|
14 |
<A HREF="spec12.html"><IMG SRC="../images/index.gif" ALT="document index"></A>
|
|
|
15 |
<P>
|
|
|
16 |
<HR>
|
|
|
17 |
<DL>
|
|
|
18 |
<DT><A HREF="#M296"><B>5.1</B> - ACCESS</A><DD>
|
|
|
19 |
<DL>
|
|
|
20 |
<DT><A HREF="#M3"><B>5.1.1</B> - access_apply_token</A><DD>
|
|
|
21 |
<DT><A HREF="#M4"><B>5.1.2</B> - access_cond</A><DD>
|
|
|
22 |
<DT><A HREF="#M5"><B>5.1.3</B> - add_accesses</A><DD>
|
|
|
23 |
<DT><A HREF="#M6"><B>5.1.4</B> - constant</A><DD>
|
|
|
24 |
<DT><A HREF="#M7"><B>5.1.5</B> - long_jump_access</A><DD>
|
|
|
25 |
<DT><A HREF="#M8"><B>5.1.6</B> - no_other_read</A><DD>
|
|
|
26 |
<DT><A HREF="#M9"><B>5.1.7</B> - no_other_write</A><DD>
|
|
|
27 |
<DT><A HREF="#M10"><B>5.1.8</B> - out_par</A><DD>
|
|
|
28 |
<DT><A HREF="#M11"><B>5.1.9</B> - preserve</A><DD>
|
|
|
29 |
<DT><A HREF="#M12"><B>5.1.10</B> - register</A><DD>
|
|
|
30 |
<DT><A HREF="#M13"><B>5.1.11</B> - standard_access</A><DD>
|
|
|
31 |
<DT><A HREF="#M14"><B>5.1.12</B> - used_as_volatile</A><DD>
|
|
|
32 |
<DT><A HREF="#M15"><B>5.1.13</B> - visible</A><DD>
|
|
|
33 |
</DL>
|
|
|
34 |
<DT><A HREF="#M297"><B>5.2</B> - AL_TAG</A><DD>
|
|
|
35 |
<DL>
|
|
|
36 |
<DT><A HREF="#M17"><B>5.2.1</B> - al_tag_apply_token</A><DD>
|
|
|
37 |
<DT><A HREF="#M18"><B>5.2.2</B> - make_al_tag</A><DD>
|
|
|
38 |
</DL>
|
|
|
39 |
<DT><A HREF="#M19"><B>5.3</B> - AL_TAGDEF</A><DD>
|
|
|
40 |
<DL>
|
|
|
41 |
<DT><A HREF="#M20"><B>5.3.1</B> - make_al_tagdef</A><DD>
|
|
|
42 |
</DL>
|
|
|
43 |
<DT><A HREF="#M21"><B>5.4</B> - AL_TAGDEF_PROPS</A><DD>
|
|
|
44 |
<DL>
|
|
|
45 |
<DT><A HREF="#M22"><B>5.4.1</B> - make_al_tagdefs</A><DD>
|
|
|
46 |
</DL>
|
|
|
47 |
<DT><A HREF="#M26"><B>5.5</B> - ALIGNMENT</A><DD>
|
|
|
48 |
<DL>
|
|
|
49 |
<DT><A HREF="#M24"><B>5.5.1</B> - alignment_apply_token</A><DD>
|
|
|
50 |
<DT><A HREF="#M25"><B>5.5.2</B> - alignment_cond</A><DD>
|
|
|
51 |
<DT><A HREF="#M26"><B>5.5.3</B> - alignment</A><DD>
|
|
|
52 |
<DT><A HREF="#M27"><B>5.5.4</B> - alloca_alignment</A><DD>
|
|
|
53 |
<DT><A HREF="#M28"><B>5.5.5</B> - callees_alignment</A><DD>
|
|
|
54 |
<DT><A HREF="#M29"><B>5.5.6</B> - callers_alignment</A><DD>
|
|
|
55 |
<DT><A HREF="#M30"><B>5.5.7</B> - code_alignment</A><DD>
|
|
|
56 |
<DT><A HREF="#M31"><B>5.5.8</B> - locals_alignment</A><DD>
|
|
|
57 |
<DT><A HREF="#M32"><B>5.5.9</B> - obtain_al_tag</A><DD>
|
|
|
58 |
<DT><A HREF="#M33"><B>5.5.10</B> - parameter_alignment</A><DD>
|
|
|
59 |
<DT><A HREF="#M34"><B>5.5.11</B> - unite_alignments</A><DD>
|
|
|
60 |
<DT><A HREF="#M35"><B>5.5.12</B> - var_param_alignment</A><DD>
|
|
|
61 |
</DL>
|
|
|
62 |
<DT><A HREF="#M299"><B>5.6</B> - BITFIELD_VARIETY</A><DD>
|
|
|
63 |
<DL>
|
|
|
64 |
<DT><A HREF="#M37"><B>5.6.1</B> - bfvar_apply_token</A><DD>
|
|
|
65 |
<DT><A HREF="#M38"><B>5.6.2</B> - bfvar_cond</A><DD>
|
|
|
66 |
<DT><A HREF="#M39"><B>5.6.3</B> - bfvar_bits</A><DD>
|
|
|
67 |
</DL>
|
|
|
68 |
<DT><A HREF="#M40"><B>5.7</B> - BITSTREAM</A><DD>
|
|
|
69 |
<DL>
|
|
|
70 |
</DL>
|
|
|
71 |
<DT><A HREF="#M300"><B>5.8</B> - BOOL</A><DD>
|
|
|
72 |
<DL>
|
|
|
73 |
<DT><A HREF="#M42"><B>5.8.1</B> - bool_apply_token</A><DD>
|
|
|
74 |
<DT><A HREF="#M43"><B>5.8.2</B> - bool_cond</A><DD>
|
|
|
75 |
<DT><A HREF="#M44"><B>5.8.3</B> - false</A><DD>
|
|
|
76 |
<DT><A HREF="#M45"><B>5.8.4</B> - true</A><DD>
|
|
|
77 |
</DL>
|
|
|
78 |
<DT><A HREF="#M46"><B>5.9</B> - BYTESTREAM</A><DD>
|
|
|
79 |
<DL>
|
|
|
80 |
</DL>
|
|
|
81 |
<DT><A HREF="#M47"><B>5.10</B> - CALLEES</A><DD>
|
|
|
82 |
<DL>
|
|
|
83 |
<DT><A HREF="#M48"><B>5.10.1</B> - make_callee_list</A><DD>
|
|
|
84 |
<DT><A HREF="#M49"><B>5.10.2</B> - make_dynamic_callees</A><DD>
|
|
|
85 |
<DT><A HREF="#M50"><B>5.10.3</B> - same_callees</A><DD>
|
|
|
86 |
</DL>
|
|
|
87 |
<DT><A HREF="#M51"><B>5.11</B> - CAPSULE</A><DD>
|
|
|
88 |
<DL>
|
|
|
89 |
<DT><A HREF="#M53"><B>5.11.1</B> - make_capsule</A><DD>
|
|
|
90 |
</DL>
|
|
|
91 |
<DT><A HREF="#M54"><B>5.12</B> - CAPSULE_LINK</A><DD>
|
|
|
92 |
<DL>
|
|
|
93 |
<DT><A HREF="#M55"><B>5.12.1</B> - make_capsule_link</A><DD>
|
|
|
94 |
</DL>
|
|
|
95 |
<DT><A HREF="#M56"><B>5.13</B> - CASELIM</A><DD>
|
|
|
96 |
<DL>
|
|
|
97 |
<DT><A HREF="#M58"><B>5.13.1</B> - make_caselim</A><DD>
|
|
|
98 |
</DL>
|
|
|
99 |
<DT><A HREF="#M59"><B>5.14</B> - ERROR_CODE</A><DD>
|
|
|
100 |
<DL>
|
|
|
101 |
<DT><A HREF="#M60"><B>5.14.1</B> - nil_access</A><DD>
|
|
|
102 |
<DT><A HREF="#M61"><B>5.14.2</B> - overflow</A><DD>
|
|
|
103 |
<DT><A HREF="#M62"><B>5.14.3</B> - stack_overflow</A><DD>
|
|
|
104 |
</DL>
|
|
|
105 |
<DT><A HREF="#M301"><B>5.15</B> - ERROR_TREATMENT</A><DD>
|
|
|
106 |
<DL>
|
|
|
107 |
<DT><A HREF="#M64"><B>5.15.1</B> - errt_apply_token</A><DD>
|
|
|
108 |
<DT><A HREF="#M65"><B>5.15.2</B> - errt_cond</A><DD>
|
|
|
109 |
<DT><A HREF="#M66"><B>5.15.3</B> - continue</A><DD>
|
|
|
110 |
<DT><A HREF="#M68"><B>5.15.4</B> - error_jump</A><DD>
|
|
|
111 |
<DT><A HREF="#M69"><B>5.15.5</B> - trap</A><DD>
|
|
|
112 |
<DT><A HREF="#M70"><B>5.15.6</B> - wrap</A><DD>
|
|
|
113 |
<DT><A HREF="#M71"><B>5.15.7</B> - impossible</A><DD>
|
|
|
114 |
</DL>
|
|
|
115 |
<DT><A HREF="#M302"><B>5.16</B> - EXP</A><DD>
|
|
|
116 |
<DL>
|
|
|
117 |
<DT><A HREF="#M73"><B>5.16.1</B> - exp_apply_token</A><DD>
|
|
|
118 |
<DT><A HREF="#M75"><B>5.16.2</B> - exp_cond</A><DD>
|
|
|
119 |
<DT><A HREF="#M76"><B>5.16.3</B> - abs</A><DD>
|
|
|
120 |
<DT><A HREF="#M77"><B>5.16.4</B> - add_to_ptr</A><DD>
|
|
|
121 |
<DT><A HREF="#M78"><B>5.16.5</B> - and</A><DD>
|
|
|
122 |
<DT><A HREF="#M80"><B>5.16.6</B> - apply_proc</A><DD>
|
|
|
123 |
<DT><A HREF="#M81"><B>5.16.7</B> - apply_general_proc</A><DD>
|
|
|
124 |
<DT><A HREF="#M82"><B>5.16.8</B> - assign</A><DD>
|
|
|
125 |
<DT><A HREF="#M83"><B>5.16.9</B> - assign_with_mode</A><DD>
|
|
|
126 |
<DT><A HREF="#M84"><B>5.16.10</B> - bitfield_assign</A><DD>
|
|
|
127 |
<DT><A HREF="#M85"><B>5.16.11</B> - bitfield_assign_with_mode</A><DD>
|
|
|
128 |
<DT><A HREF="#M86"><B>5.16.12</B> - bitfield_contents</A><DD>
|
|
|
129 |
<DT><A HREF="#M87"><B>5.16.13</B> - bitfield_contents_with_mode</A><DD>
|
|
|
130 |
<DT><A HREF="#M89"><B>5.16.14</B> - case</A><DD>
|
|
|
131 |
<DT><A HREF="#M90"><B>5.16.15</B> - change_bitfield_to_int</A><DD>
|
|
|
132 |
<DT><A HREF="#M91"><B>5.16.16</B> - change_floating_variety</A><DD>
|
|
|
133 |
<DT><A HREF="#M92"><B>5.16.17</B> - change_variety</A><DD>
|
|
|
134 |
<DT><A HREF="#M93"><B>5.16.18</B> - change_int_to_bitfield</A><DD>
|
|
|
135 |
<DT><A HREF="#M94"><B>5.16.19</B> - complex_conjugate</A><DD>
|
|
|
136 |
<DT><A HREF="#M95"><B>5.16.20</B> - component</A><DD>
|
|
|
137 |
<DT><A HREF="#M96"><B>5.16.21</B> - concat_nof</A><DD>
|
|
|
138 |
<DT><A HREF="#M97"><B>5.16.22</B> - conditional</A><DD>
|
|
|
139 |
<DT><A HREF="#M98"><B>5.16.23</B> - contents</A><DD>
|
|
|
140 |
<DT><A HREF="#M99"><B>5.16.24</B> - contents_with_mode</A><DD>
|
|
|
141 |
<DT><A HREF="#M101"><B>5.16.25</B> - current_env</A><DD>
|
|
|
142 |
<DT><A HREF="#M102"><B>5.16.26</B> - div0</A><DD>
|
|
|
143 |
<DT><A HREF="#M103"><B>5.16.27</B> - div1</A><DD>
|
|
|
144 |
<DT><A HREF="#M104"><B>5.16.28</B> - div2</A><DD>
|
|
|
145 |
<DT><A HREF="#M105"><B>5.16.29</B> - env_offset</A><DD>
|
|
|
146 |
<DT><A HREF="#M106"><B>5.16.30</B> - env_size</A><DD>
|
|
|
147 |
<DT><A HREF="#M107"><B>5.16.31</B> - fail_installer</A><DD>
|
|
|
148 |
<DT><A HREF="#M108"><B>5.16.32</B> - float_int</A><DD>
|
|
|
149 |
<DT><A HREF="#M109"><B>5.16.33</B> - floating_abs</A><DD>
|
|
|
150 |
<DT><A HREF="#M110"><B>5.16.34</B> - floating_div</A><DD>
|
|
|
151 |
<DT><A HREF="#M111"><B>5.16.35</B> - floating_minus</A><DD>
|
|
|
152 |
<DT><A HREF="#M112"><B>5.16.36</B> - floating_maximum</A><DD>
|
|
|
153 |
<DT><A HREF="#M113"><B>5.16.37</B> - floating_minimum</A><DD>
|
|
|
154 |
<DT><A HREF="#M114"><B>5.16.38</B> - floating_mult</A><DD>
|
|
|
155 |
<DT><A HREF="#M116"><B>5.16.39</B> - floating_negate</A><DD>
|
|
|
156 |
<DT><A HREF="#M117"><B>5.16.40</B> - floating_plus</A><DD>
|
|
|
157 |
<DT><A HREF="#M118"><B>5.16.41</B> - floating_power</A><DD>
|
|
|
158 |
<DT><A HREF="#M119"><B>5.16.42</B> - floating_test</A><DD>
|
|
|
159 |
<DT><A HREF="#M120"><B>5.16.43</B> - goto</A><DD>
|
|
|
160 |
<DT><A HREF="#M121"><B>5.16.44</B> - goto_local_lv</A><DD>
|
|
|
161 |
<DT><A HREF="#M122"><B>5.16.45</B> - identify</A><DD>
|
|
|
162 |
<DT><A HREF="#M123"><B>5.16.46</B> - ignorable</A><DD>
|
|
|
163 |
<DT><A HREF="#M124"><B>5.16.47</B> - imaginary_part</A><DD>
|
|
|
164 |
<DT><A HREF="#M125"><B>5.16.48</B> - initial_value</A><DD>
|
|
|
165 |
<DT><A HREF="#M127"><B>5.16.49</B> - integer_test</A><DD>
|
|
|
166 |
<DT><A HREF="#M128"><B>5.16.50</B> - labelled</A><DD>
|
|
|
167 |
<DT><A HREF="#M129"><B>5.16.51</B> - last_local</A><DD>
|
|
|
168 |
<DT><A HREF="#M130"><B>5.16.52</B> - local_alloc</A><DD>
|
|
|
169 |
<DT><A HREF="#M132"><B>5.16.53</B> - local_alloc_check</A><DD>
|
|
|
170 |
<DT><A HREF="#M133"><B>5.16.54</B> - local_free</A><DD>
|
|
|
171 |
<DT><A HREF="#M134"><B>5.16.55</B> - local_free_all</A><DD>
|
|
|
172 |
<DT><A HREF="#M135"><B>5.16.56</B> - long_jump</A><DD>
|
|
|
173 |
<DT><A HREF="#M136"><B>5.16.57</B> - make_complex</A><DD>
|
|
|
174 |
<DT><A HREF="#M137"><B>5.16.58</B> - make_compound</A><DD>
|
|
|
175 |
<DT><A HREF="#M138"><B>5.16.59</B> - make_floating</A><DD>
|
|
|
176 |
<DT><A HREF="#M139"><B>5.16.60</B> - make_general_proc</A><DD>
|
|
|
177 |
<DT><A HREF="#M141"><B>5.16.61</B> - make_int</A><DD>
|
|
|
178 |
<DT><A HREF="#M142"><B>5.16.62</B> - make_local_lv</A><DD>
|
|
|
179 |
<DT><A HREF="#M143"><B>5.16.63</B> - make_nof</A><DD>
|
|
|
180 |
<DT><A HREF="#M144"><B>5.16.64</B> - make_nof_int</A><DD>
|
|
|
181 |
<DT><A HREF="#M145"><B>5.16.65</B> - make_null_local_lv</A><DD>
|
|
|
182 |
<DT><A HREF="#M146"><B>5.16.66</B> - make_null_proc</A><DD>
|
|
|
183 |
<DT><A HREF="#M147"><B>5.16.67</B> - make_null_ptr</A><DD>
|
|
|
184 |
<DT><A HREF="#M148"><B>5.16.68</B> - make_proc</A><DD>
|
|
|
185 |
<DT><A HREF="#M150"><B>5.16.69</B> - make_stack_limit</A><DD>
|
|
|
186 |
<DT><A HREF="#M151"><B>5.16.70</B> - make_top</A><DD>
|
|
|
187 |
<DT><A HREF="#M152"><B>5.16.71</B> - make_value</A><DD>
|
|
|
188 |
<DT><A HREF="#M153"><B>5.16.72</B> - maximum</A><DD>
|
|
|
189 |
<DT><A HREF="#M154"><B>5.16.73</B> - minimum</A><DD>
|
|
|
190 |
<DT><A HREF="#M155"><B>5.16.74</B> - minus</A><DD>
|
|
|
191 |
<DT><A HREF="#M156"><B>5.16.75</B> - move_some</A><DD>
|
|
|
192 |
<DT><A HREF="#M157"><B>5.16.76</B> - mult</A><DD>
|
|
|
193 |
<DT><A HREF="#M158"><B>5.16.77</B> - n_copies</A><DD>
|
|
|
194 |
<DT><A HREF="#M159"><B>5.16.78</B> - negate</A><DD>
|
|
|
195 |
<DT><A HREF="#M160"><B>5.16.79</B> - not</A><DD>
|
|
|
196 |
<DT><A HREF="#M161"><B>5.16.80</B> - obtain_tag</A><DD>
|
|
|
197 |
<DT><A HREF="#M162"><B>5.16.81</B> - offset_add</A><DD>
|
|
|
198 |
<DT><A HREF="#M163"><B>5.16.82</B> - offset_div</A><DD>
|
|
|
199 |
<DT><A HREF="#M164"><B>5.16.83</B> - offset_div_by_int</A><DD>
|
|
|
200 |
<DT><A HREF="#M165"><B>5.16.84</B> - offset_max</A><DD>
|
|
|
201 |
<DT><A HREF="#M166"><B>5.16.85</B> - offset_mult</A><DD>
|
|
|
202 |
<DT><A HREF="#M167"><B>5.16.86</B> - offset_negate</A><DD>
|
|
|
203 |
<DT><A HREF="#M169"><B>5.16.87</B> - offset_pad</A><DD>
|
|
|
204 |
<DT><A HREF="#M170"><B>5.16.88</B> - offset_subtract</A><DD>
|
|
|
205 |
<DT><A HREF="#M172"><B>5.16.89</B> - offset_test</A><DD>
|
|
|
206 |
<DT><A HREF="#M173"><B>5.16.90</B> - offset_zero</A><DD>
|
|
|
207 |
<DT><A HREF="#M174"><B>5.16.91</B> - or</A><DD>
|
|
|
208 |
<DT><A HREF="#M175"><B>5.16.92</B> - plus</A><DD>
|
|
|
209 |
<DT><A HREF="#M176"><B>5.16.93</B> - pointer_test</A><DD>
|
|
|
210 |
<DT><A HREF="#M177"><B>5.16.94</B> - power</A><DD>
|
|
|
211 |
<DT><A HREF="#M178"><B>5.16.95</B> - proc_test</A><DD>
|
|
|
212 |
<DT><A HREF="#M179"><B>5.16.96</B> - profile</A><DD>
|
|
|
213 |
<DT><A HREF="#M180"><B>5.16.97</B> - real_part</A><DD>
|
|
|
214 |
<DT><A HREF="#M181"><B>5.16.98</B> - rem0</A><DD>
|
|
|
215 |
<DT><A HREF="#M182"><B>5.16.99</B> - rem1</A><DD>
|
|
|
216 |
<DT><A HREF="#M183"><B>5.16.100</B> - rem2</A><DD>
|
|
|
217 |
<DT><A HREF="#M184"><B>5.16.101</B> - repeat</A><DD>
|
|
|
218 |
<DT><A HREF="#M185"><B>5.16.102</B> - return</A><DD>
|
|
|
219 |
<DT><A HREF="#M186"><B>5.16.103</B> - return_to_label</A><DD>
|
|
|
220 |
<DT><A HREF="#M187"><B>5.16.104</B> - round_with_mode</A><DD>
|
|
|
221 |
<DT><A HREF="#M188"><B>5.16.105</B> - rotate_left</A><DD>
|
|
|
222 |
<DT><A HREF="#M190"><B>5.16.106</B> - rotate_right</A><DD>
|
|
|
223 |
<DT><A HREF="#M193"><B>5.16.107</B> - sequence</A><DD>
|
|
|
224 |
<DT><A HREF="#M194"><B>5.16.108</B> - set_stack_limit</A><DD>
|
|
|
225 |
<DT><A HREF="#M196"><B>5.16.109</B> - shape_offset</A><DD>
|
|
|
226 |
<DT><A HREF="#M197"><B>5.16.110</B> - shift_left</A><DD>
|
|
|
227 |
<DT><A HREF="#M198"><B>5.16.111</B> - shift_right</A><DD>
|
|
|
228 |
<DT><A HREF="#M199"><B>5.16.112</B> - subtract_ptrs</A><DD>
|
|
|
229 |
<DT><A HREF="#M200"><B>5.16.113</B> - tail_call</A><DD>
|
|
|
230 |
<DT><A HREF="#M201"><B>5.16.114</B> - untidy_return</A><DD>
|
|
|
231 |
<DT><A HREF="#M202"><B>5.16.115</B> - variable</A><DD>
|
|
|
232 |
<DT><A HREF="#M204"><B>5.16.116</B> - xor</A><DD>
|
|
|
233 |
</DL>
|
|
|
234 |
<DT><A HREF="#M205"><B>5.17</B> - EXTERNAL</A><DD>
|
|
|
235 |
<DL>
|
|
|
236 |
<DT><A HREF="#M206"><B>5.17.1</B> - string_extern</A><DD>
|
|
|
237 |
<DT><A HREF="#M207"><B>5.17.2</B> - unique_extern</A><DD>
|
|
|
238 |
<DT><A HREF="#M208"><B>5.17.3</B> - chain_extern</A><DD>
|
|
|
239 |
</DL>
|
|
|
240 |
<DT><A HREF="#M209"><B>5.18</B> - EXTERN_LINK</A><DD>
|
|
|
241 |
<DL>
|
|
|
242 |
<DT><A HREF="#M210"><B>5.18.1</B> - make_extern_link</A><DD>
|
|
|
243 |
</DL>
|
|
|
244 |
<DT><A HREF="#M303"><B>5.19</B> - FLOATING_VARIETY</A><DD>
|
|
|
245 |
<DL>
|
|
|
246 |
<DT><A HREF="#M212"><B>5.19.1</B> - flvar_apply_token</A><DD>
|
|
|
247 |
<DT><A HREF="#M213"><B>5.19.2</B> - flvar_cond</A><DD>
|
|
|
248 |
<DT><A HREF="#M214"><B>5.19.3</B> - flvar_parms</A><DD>
|
|
|
249 |
<DT><A HREF="#M215"><B>5.19.4</B> - complex_parms</A><DD>
|
|
|
250 |
<DT><A HREF="#M216"><B>5.19.5</B> - float_of_complex</A><DD>
|
|
|
251 |
<DT><A HREF="#M217"><B>5.19.6</B> - complex_of_float</A><DD>
|
|
|
252 |
</DL>
|
|
|
253 |
<DT><A HREF="#M218"><B>5.20</B> - GROUP</A><DD>
|
|
|
254 |
<DL>
|
|
|
255 |
<DT><A HREF="#M219"><B>5.20.1</B> - make_group</A><DD>
|
|
|
256 |
</DL>
|
|
|
257 |
<DT><A HREF="#M305"><B>5.21</B> - LABEL</A><DD>
|
|
|
258 |
<DL>
|
|
|
259 |
<DT><A HREF="#M221"><B>5.21.1</B> - label_apply_token</A><DD>
|
|
|
260 |
<DT><A HREF="#M222"><B>5.21.2</B> - make_label</A><DD>
|
|
|
261 |
</DL>
|
|
|
262 |
<DT><A HREF="#M223"><B>5.22</B> - LINK</A><DD>
|
|
|
263 |
<DL>
|
|
|
264 |
<DT><A HREF="#M224"><B>5.22.1</B> - make_link</A><DD>
|
|
|
265 |
</DL>
|
|
|
266 |
<DT><A HREF="#M225"><B>5.23</B> - LINKEXTERN</A><DD>
|
|
|
267 |
<DL>
|
|
|
268 |
<DT><A HREF="#M226"><B>5.23.1</B> - make_linkextern</A><DD>
|
|
|
269 |
</DL>
|
|
|
270 |
<DT><A HREF="#M227"><B>5.24</B> - LINKS</A><DD>
|
|
|
271 |
<DL>
|
|
|
272 |
<DT><A HREF="#M228"><B>5.24.1</B> - make_links</A><DD>
|
|
|
273 |
</DL>
|
|
|
274 |
<DT><A HREF="#M306"><B>5.25</B> - NAT</A><DD>
|
|
|
275 |
<DL>
|
|
|
276 |
<DT><A HREF="#M230"><B>5.25.1</B> - nat_apply_token</A><DD>
|
|
|
277 |
<DT><A HREF="#M231"><B>5.25.2</B> - nat_cond</A><DD>
|
|
|
278 |
<DT><A HREF="#M232"><B>5.25.3</B> - computed_nat</A><DD>
|
|
|
279 |
<DT><A HREF="#M233"><B>5.25.4</B> - error_val</A><DD>
|
|
|
280 |
<DT><A HREF="#M234"><B>5.25.5</B> - make_nat</A><DD>
|
|
|
281 |
</DL>
|
|
|
282 |
<DT><A HREF="#M307"><B>5.26</B> - NTEST</A><DD>
|
|
|
283 |
<DL>
|
|
|
284 |
<DT><A HREF="#M236"><B>5.26.1</B> - ntest_apply_token</A><DD>
|
|
|
285 |
<DT><A HREF="#M237"><B>5.26.2</B> - ntest_cond</A><DD>
|
|
|
286 |
<DT><A HREF="#M238"><B>5.26.3</B> - equal</A><DD>
|
|
|
287 |
<DT><A HREF="#M239"><B>5.26.4</B> - greater_than</A><DD>
|
|
|
288 |
<DT><A HREF="#M240"><B>5.26.5</B> - greater_than_or_equal</A><DD>
|
|
|
289 |
<DT><A HREF="#M241"><B>5.26.6</B> - less_than</A><DD>
|
|
|
290 |
<DT><A HREF="#M242"><B>5.26.7</B> - less_than_or_equal</A><DD>
|
|
|
291 |
<DT><A HREF="#M243"><B>5.26.8</B> - not_equal</A><DD>
|
|
|
292 |
<DT><A HREF="#M244"><B>5.26.9</B> - not_greater_than</A><DD>
|
|
|
293 |
<DT><A HREF="#M245"><B>5.26.10</B> - not_greater_than_or_equal</A><DD>
|
|
|
294 |
<DT><A HREF="#M246"><B>5.26.11</B> - not_less_than</A><DD>
|
|
|
295 |
<DT><A HREF="#M247"><B>5.26.12</B> - not_less_than_or_equal</A><DD>
|
|
|
296 |
<DT><A HREF="#M248"><B>5.26.13</B> - less_than_or_greater_than</A><DD>
|
|
|
297 |
<DT><A HREF="#M249"><B>5.26.14</B> - not_less_than_and_not_greater_than</A><DD>
|
|
|
298 |
<DT><A HREF="#M250"><B>5.26.15</B> - comparable</A><DD>
|
|
|
299 |
<DT><A HREF="#M251"><B>5.26.16</B> - not_comparable</A><DD>
|
|
|
300 |
</DL>
|
|
|
301 |
<DT><A HREF="#M252"><B>5.27</B> - OTAGEXP</A><DD>
|
|
|
302 |
<DL>
|
|
|
303 |
<DT><A HREF="#M253"><B>5.27.1</B> - make_otagexp</A><DD>
|
|
|
304 |
</DL>
|
|
|
305 |
<DT><A HREF="#M308"><B>5.28</B> - PROCPROPS</A><DD>
|
|
|
306 |
<DL>
|
|
|
307 |
<DT><A HREF="#M256"><B>5.28.1</B> - procprops_apply_token</A><DD>
|
|
|
308 |
<DT><A HREF="#M257"><B>5.28.2</B> - procprops_cond</A><DD>
|
|
|
309 |
<DT><A HREF="#M258"><B>5.28.3</B> - add_procprops</A><DD>
|
|
|
310 |
<DT><A HREF="#M259"><B>5.28.4</B> - check_stack</A><DD>
|
|
|
311 |
<DT><A HREF="#M260"><B>5.28.5</B> - inline</A><DD>
|
|
|
312 |
<DT><A HREF="#M261"><B>5.28.6</B> - no_long_jump_dest</A><DD>
|
|
|
313 |
<DT><A HREF="#M262"><B>5.28.7</B> - untidy</A><DD>
|
|
|
314 |
<DT><A HREF="#M263"><B>5.28.8</B> - var_callees</A><DD>
|
|
|
315 |
<DT><A HREF="#M264"><B>5.28.9</B> - var_callers</A><DD>
|
|
|
316 |
</DL>
|
|
|
317 |
<DT><A HREF="#M266"><B>5.29</B> - PROPS</A><DD>
|
|
|
318 |
<DL>
|
|
|
319 |
</DL>
|
|
|
320 |
<DT><A HREF="#M309"><B>5.30</B> - ROUNDING_MODE</A><DD>
|
|
|
321 |
<DL>
|
|
|
322 |
<DT><A HREF="#M268"><B>5.30.1</B> - rounding_mode_apply_token</A><DD>
|
|
|
323 |
<DT><A HREF="#M269"><B>5.30.2</B> - rounding_mode_cond</A><DD>
|
|
|
324 |
<DT><A HREF="#M270"><B>5.30.3</B> - round_as_state</A><DD>
|
|
|
325 |
<DT><A HREF="#M271"><B>5.30.4</B> - to_nearest</A><DD>
|
|
|
326 |
<DT><A HREF="#M272"><B>5.30.5</B> - toward_larger</A><DD>
|
|
|
327 |
<DT><A HREF="#M273"><B>5.30.6</B> - toward_smaller</A><DD>
|
|
|
328 |
<DT><A HREF="#M274"><B>5.30.7</B> - toward_zero</A><DD>
|
|
|
329 |
</DL>
|
|
|
330 |
<DT><A HREF="#M310"><B>5.31</B> - SHAPE</A><DD>
|
|
|
331 |
<DL>
|
|
|
332 |
<DT><A HREF="#M276"><B>5.31.1</B> - shape_apply_token</A><DD>
|
|
|
333 |
<DT><A HREF="#M277"><B>5.31.2</B> - shape_cond</A><DD>
|
|
|
334 |
<DT><A HREF="#M278"><B>5.31.3</B> - bitfield</A><DD>
|
|
|
335 |
<DT><A HREF="#M279"><B>5.31.4</B> - bottom</A><DD>
|
|
|
336 |
<DT><A HREF="#M280"><B>5.31.5</B> - compound</A><DD>
|
|
|
337 |
<DT><A HREF="#M282"><B>5.31.6</B> - floating</A><DD>
|
|
|
338 |
<DT><A HREF="#M283"><B>5.31.7</B> - integer</A><DD>
|
|
|
339 |
<DT><A HREF="#M284"><B>5.31.8</B> - nof</A><DD>
|
|
|
340 |
<DT><A HREF="#M285"><B>5.31.9</B> - offset</A><DD>
|
|
|
341 |
<DT><A HREF="#M286"><B>5.31.10</B> - pointer</A><DD>
|
|
|
342 |
<DT><A HREF="#M287"><B>5.31.11</B> - proc</A><DD>
|
|
|
343 |
<DT><A HREF="#M288"><B>5.31.12</B> - top</A><DD>
|
|
|
344 |
</DL>
|
|
|
345 |
<DT><A HREF="#M311"><B>5.32</B> - SIGNED_NAT</A><DD>
|
|
|
346 |
<DL>
|
|
|
347 |
<DT><A HREF="#M290"><B>5.32.1</B> - signed_nat_apply_token</A><DD>
|
|
|
348 |
<DT><A HREF="#M291"><B>5.32.2</B> - signed_nat_cond</A><DD>
|
|
|
349 |
<DT><A HREF="#M292"><B>5.32.3</B> - computed_signed_nat</A><DD>
|
|
|
350 |
<DT><A HREF="#M293"><B>5.32.4</B> - make_signed_nat</A><DD>
|
|
|
351 |
<DT><A HREF="#M294"><B>5.32.5</B> - snat_from_nat</A><DD>
|
|
|
352 |
</DL>
|
|
|
353 |
<DT><A HREF="#M295"><B>5.33</B> - SORTNAME</A><DD>
|
|
|
354 |
<DL>
|
|
|
355 |
<DT><A HREF="#M296A"><B>5.33.1</B> - access</A><DD>
|
|
|
356 |
<DT><A HREF="#M297A"><B>5.33.2</B> - al_tag</A><DD>
|
|
|
357 |
<DT><A HREF="#M298"><B>5.33.3</B> - alignment_sort</A><DD>
|
|
|
358 |
<DT><A HREF="#M299A"><B>5.33.4</B> - bitfield_variety</A><DD>
|
|
|
359 |
<DT><A HREF="#M300A"><B>5.33.5</B> - bool</A><DD>
|
|
|
360 |
<DT><A HREF="#M301A"><B>5.33.6</B> - error_treatment</A><DD>
|
|
|
361 |
<DT><A HREF="#M302A"><B>5.33.7</B> - exp</A><DD>
|
|
|
362 |
<DT><A HREF="#M303A"><B>5.33.8</B> - floating_variety</A><DD>
|
|
|
363 |
<DT><A HREF="#M304"><B>5.33.9</B> - foreign_sort</A><DD>
|
|
|
364 |
<DT><A HREF="#M305A"><B>5.33.10</B> - label</A><DD>
|
|
|
365 |
<DT><A HREF="#M306A"><B>5.33.11</B> - nat</A><DD>
|
|
|
366 |
<DT><A HREF="#M307A"><B>5.33.12</B> - ntest</A><DD>
|
|
|
367 |
<DT><A HREF="#M308A"><B>5.33.13</B> - procprops</A><DD>
|
|
|
368 |
<DT><A HREF="#M309A"><B>5.33.14</B> - rounding_mode</A><DD>
|
|
|
369 |
<DT><A HREF="#M310A"><B>5.33.15</B> - shape</A><DD>
|
|
|
370 |
<DT><A HREF="#M311A"><B>5.33.16</B> - signed_nat</A><DD>
|
|
|
371 |
<DT><A HREF="#M317A"><B>5.33.17</B> - string</A><DD>
|
|
|
372 |
<DT><A HREF="#M322A"><B>5.33.18</B> - tag</A><DD>
|
|
|
373 |
<DT><A HREF="#M365A"><B>5.33.19</B> - transfer_mode</A><DD>
|
|
|
374 |
<DT><A HREF="#M356A"><B>5.33.20</B> - token</A><DD>
|
|
|
375 |
<DT><A HREF="#M378A"><B>5.33.21</B> - variety</A><DD>
|
|
|
376 |
</DL>
|
|
|
377 |
<DT><A HREF="#M317"><B>5.34</B> - STRING</A><DD>
|
|
|
378 |
<DL>
|
|
|
379 |
<DT><A HREF="#M318"><B>5.34.1</B> - string_apply_token</A><DD>
|
|
|
380 |
<DT><A HREF="#M319"><B>5.34.2</B> - string_cond</A><DD>
|
|
|
381 |
<DT><A HREF="#M320"><B>5.34.3</B> - concat_string</A><DD>
|
|
|
382 |
<DT><A HREF="#M321"><B>5.34.4</B> - make_string</A><DD>
|
|
|
383 |
</DL>
|
|
|
384 |
<DT><A HREF="#M322"><B>5.35</B> - TAG</A><DD>
|
|
|
385 |
<DL>
|
|
|
386 |
<DT><A HREF="#M323"><B>5.35.1</B> - tag_apply_token</A><DD>
|
|
|
387 |
<DT><A HREF="#M324"><B>5.35.2</B> - make_tag</A><DD>
|
|
|
388 |
</DL>
|
|
|
389 |
<DT><A HREF="#M325"><B>5.36</B> - TAGACC</A><DD>
|
|
|
390 |
<DL>
|
|
|
391 |
<DT><A HREF="#M326"><B>5.36.1</B> - make_tagacc</A><DD>
|
|
|
392 |
</DL>
|
|
|
393 |
<DT><A HREF="#M327"><B>5.37</B> - TAGDEC</A><DD>
|
|
|
394 |
<DL>
|
|
|
395 |
<DT><A HREF="#M328"><B>5.37.1</B> - make_id_tagdec</A><DD>
|
|
|
396 |
<DT><A HREF="#M329"><B>5.37.2</B> - make_var_tagdec</A><DD>
|
|
|
397 |
<DT><A HREF="#M331"><B>5.37.3</B> - common_tagdec</A><DD>
|
|
|
398 |
</DL>
|
|
|
399 |
<DT><A HREF="#M332"><B>5.38</B> - TAGDEC_PROPS</A><DD>
|
|
|
400 |
<DL>
|
|
|
401 |
<DT><A HREF="#M333"><B>5.38.1</B> - make_tagdecs</A><DD>
|
|
|
402 |
</DL>
|
|
|
403 |
<DT><A HREF="#M334"><B>5.39</B> - TAGDEF</A><DD>
|
|
|
404 |
<DL>
|
|
|
405 |
<DT><A HREF="#M335"><B>5.39.1</B> - make_id_tagdef</A><DD>
|
|
|
406 |
<DT><A HREF="#M336"><B>5.39.2</B> - make_var_tagdef</A><DD>
|
|
|
407 |
<DT><A HREF="#M338"><B>5.39.3</B> - common_tagdef</A><DD>
|
|
|
408 |
</DL>
|
|
|
409 |
<DT><A HREF="#M340"><B>5.40</B> - TAGDEF_PROPS</A><DD>
|
|
|
410 |
<DL>
|
|
|
411 |
<DT><A HREF="#M341"><B>5.40.1</B> - make_tagdefs</A><DD>
|
|
|
412 |
</DL>
|
|
|
413 |
<DT><A HREF="#M342"><B>5.41</B> - TAGSHACC</A><DD>
|
|
|
414 |
<DL>
|
|
|
415 |
<DT><A HREF="#M343"><B>5.41.1</B> - make_tagshacc</A><DD>
|
|
|
416 |
</DL>
|
|
|
417 |
<DT><A HREF="#M344"><B>5.42</B> - TDFBOOL</A><DD>
|
|
|
418 |
<DL>
|
|
|
419 |
</DL>
|
|
|
420 |
<DT><A HREF="#M345"><B>5.43</B> - TDFIDENT</A><DD>
|
|
|
421 |
<DL>
|
|
|
422 |
</DL>
|
|
|
423 |
<DT><A HREF="#M346"><B>5.44</B> - TDFINT</A><DD>
|
|
|
424 |
<DL>
|
|
|
425 |
</DL>
|
|
|
426 |
<DT><A HREF="#M347"><B>5.45</B> - TDFSTRING</A><DD>
|
|
|
427 |
<DL>
|
|
|
428 |
</DL>
|
|
|
429 |
<DT><A HREF="#M348"><B>5.46</B> - TOKDEC</A><DD>
|
|
|
430 |
<DL>
|
|
|
431 |
<DT><A HREF="#M349"><B>5.46.1</B> - make_tokdec</A><DD>
|
|
|
432 |
</DL>
|
|
|
433 |
<DT><A HREF="#M350"><B>5.47</B> - TOKDEC_PROPS</A><DD>
|
|
|
434 |
<DL>
|
|
|
435 |
<DT><A HREF="#M351"><B>5.47.1</B> - make_tokdecs</A><DD>
|
|
|
436 |
</DL>
|
|
|
437 |
<DT><A HREF="#M352"><B>5.48</B> - TOKDEF</A><DD>
|
|
|
438 |
<DL>
|
|
|
439 |
<DT><A HREF="#M353"><B>5.48.1</B> - make_tokdef</A><DD>
|
|
|
440 |
</DL>
|
|
|
441 |
<DT><A HREF="#M354"><B>5.49</B> - TOKDEF_PROPS</A><DD>
|
|
|
442 |
<DL>
|
|
|
443 |
<DT><A HREF="#M355"><B>5.49.1</B> - make_tokdefs</A><DD>
|
|
|
444 |
</DL>
|
|
|
445 |
<DT><A HREF="#M356"><B>5.50</B> - TOKEN</A><DD>
|
|
|
446 |
<DL>
|
|
|
447 |
<DT><A HREF="#M357"><B>5.50.1</B> - token_apply_token</A><DD>
|
|
|
448 |
<DT><A HREF="#M358"><B>5.50.2</B> - make_tok</A><DD>
|
|
|
449 |
<DT><A HREF="#M359"><B>5.50.3</B> - use_tokdef</A><DD>
|
|
|
450 |
</DL>
|
|
|
451 |
<DT><A HREF="#M360"><B>5.51</B> - TOKEN_DEFN</A><DD>
|
|
|
452 |
<DL>
|
|
|
453 |
<DT><A HREF="#M362"><B>5.51.1</B> - token_definition</A><DD>
|
|
|
454 |
</DL>
|
|
|
455 |
<DT><A HREF="#M363"><B>5.52</B> - TOKFORMALS</A><DD>
|
|
|
456 |
<DL>
|
|
|
457 |
<DT><A HREF="#M364"><B>5.52.1</B> - make_tokformals</A><DD>
|
|
|
458 |
</DL>
|
|
|
459 |
<DT><A HREF="#M365"><B>5.53</B> - TRANSFER_MODE</A><DD>
|
|
|
460 |
<DL>
|
|
|
461 |
<DT><A HREF="#M366"><B>5.53.1</B> - transfer_mode_apply_token</A><DD>
|
|
|
462 |
<DT><A HREF="#M367"><B>5.53.2</B> - transfer_mode_cond</A><DD>
|
|
|
463 |
<DT><A HREF="#M368"><B>5.53.3</B> - add_modes</A><DD>
|
|
|
464 |
<DT><A HREF="#M369"><B>5.53.4</B> - overlap</A><DD>
|
|
|
465 |
<DT><A HREF="#M370"><B>5.53.5</B> - standard_transfer_mode</A><DD>
|
|
|
466 |
<DT><A HREF="#M371"><B>5.53.6</B> - trap_on_nil</A><DD>
|
|
|
467 |
<DT><A HREF="#M372"><B>5.53.7</B> - volatile</A><DD>
|
|
|
468 |
<DT><A HREF="#M373"><B>5.53.8</B> - complete</A><DD>
|
|
|
469 |
</DL>
|
|
|
470 |
<DT><A HREF="#M374"><B>5.54</B> - UNIQUE</A><DD>
|
|
|
471 |
<DL>
|
|
|
472 |
<DT><A HREF="#M375"><B>5.54.1</B> - make_unique</A><DD>
|
|
|
473 |
</DL>
|
|
|
474 |
<DT><A HREF="#M376"><B>5.55</B> - UNIT</A><DD>
|
|
|
475 |
<DL>
|
|
|
476 |
<DT><A HREF="#M377"><B>5.55.1</B> - make_unit</A><DD>
|
|
|
477 |
</DL>
|
|
|
478 |
<DT><A HREF="#M378"><B>5.56</B> - VARIETY</A><DD>
|
|
|
479 |
<DL>
|
|
|
480 |
<DT><A HREF="#M379"><B>5.56.1</B> - var_apply_token</A><DD>
|
|
|
481 |
<DT><A HREF="#M380"><B>5.56.2</B> - var_cond</A><DD>
|
|
|
482 |
<DT><A HREF="#M381"><B>5.56.3</B> - var_limits</A><DD>
|
|
|
483 |
<DT><A HREF="#M382"><B>5.56.4</B> - var_width</A><DD>
|
|
|
484 |
</DL>
|
|
|
485 |
<DT><A HREF="#M383"><B>5.57</B> - VERSION_PROPS</A><DD>
|
|
|
486 |
<DL>
|
|
|
487 |
<DT><A HREF="#M384"><B>5.57.1</B> - make_versions</A><DD>
|
|
|
488 |
</DL>
|
|
|
489 |
<DT><A HREF="#M385"><B>5.58</B> - VERSION</A><DD>
|
|
|
490 |
<DL>
|
|
|
491 |
<DT><A HREF="#M386"><B>5.58.1</B> - make_version</A><DD>
|
|
|
492 |
<DT><A HREF="#M387"><B>5.58.2</B> - user_info</A><DD>
|
|
|
493 |
</DL>
|
|
|
494 |
</DL>
|
|
|
495 |
<HR>
|
|
|
496 |
<H1>5. Specification of TDF Constructs</H1>
|
|
|
497 |
|
|
|
498 |
<HR>
|
|
|
499 |
<H2>5.1. <A NAME=M296>ACCESS</A></H2>
|
|
|
500 |
<B>Number of encoding bits</B>: 4<BR>
|
|
|
501 |
<B>Is coding extendable</B>: yes<P>
|
|
|
502 |
An <CODE>ACCESS</CODE> describes properties a variable or identity
|
|
|
503 |
may have which may constrain or describe the ways in which the variable
|
|
|
504 |
or identity is used.
|
|
|
505 |
<P>
|
|
|
506 |
Each construction which needs an <CODE>ACCESS</CODE> uses it in the
|
|
|
507 |
form <CODE>OPTION</CODE>(<CODE>ACCESS</CODE>). If the option is absent
|
|
|
508 |
the variable or identity has no special properties.
|
|
|
509 |
<P>
|
|
|
510 |
An <CODE>ACCESS</CODE> acts like a set of the values <I>constant</I>,
|
|
|
511 |
<I>long_jump_access</I>, <I>no_other_read</I>, <I>no_other_write</I>,
|
|
|
512 |
<I>register</I>, <I>out_par</I>, <I>used_as_volatile</I>, and
|
|
|
513 |
<I>visible</I>. <I>standard_access</I> acts like the empty set.
|
|
|
514 |
<I>add_accesses</I> is the set union operation.
|
|
|
515 |
<P>
|
|
|
516 |
|
|
|
517 |
<H3>5.1.1. <A NAME=M3>access_apply_token</A></H3>
|
|
|
518 |
<B>Encoding number</B>: 1<P>
|
|
|
519 |
<PRE>
|
|
|
520 |
<I>token_value</I>: TOKEN
|
|
|
521 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
522 |
-> ACCESS
|
|
|
523 |
</PRE>
|
|
|
524 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
525 |
<I>token_args</I> to give an <CODE>ACCESS</CODE>.
|
|
|
526 |
<P>
|
|
|
527 |
The notation <I>param_sorts(token_value)</I> is intended to mean the
|
|
|
528 |
following. The token definition or token declaration for
|
|
|
529 |
<I>token_value</I> gives the <CODE>SORT</CODE>s of its arguments in
|
|
|
530 |
the
|
|
|
531 |
<CODE>SORTNAME</CODE> component. The <CODE>BITSTREAM</CODE> in
|
|
|
532 |
<I>token_args</I> consists of these <CODE>SORT</CODE>s in the given
|
|
|
533 |
order. If no token declaration or definition exists in the
|
|
|
534 |
<CODE>CAPSULE</CODE>, the <CODE>BITSTREAM</CODE> cannot be read.
|
|
|
535 |
<P>
|
|
|
536 |
|
|
|
537 |
<H3>5.1.2. <A NAME=M4>access_cond</A></H3>
|
|
|
538 |
<B>Encoding number</B>: 2<P>
|
|
|
539 |
<PRE>
|
|
|
540 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
541 |
<I>e1</I>: BITSTREAM ACCESS
|
|
|
542 |
<I>e2</I>: BITSTREAM ACCESS
|
|
|
543 |
-> ACCESS
|
|
|
544 |
</PRE>
|
|
|
545 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
546 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
547 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
548 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
549 |
and <I>e1</I> is ignored and never processed.
|
|
|
550 |
<P>
|
|
|
551 |
|
|
|
552 |
<H3>5.1.3. <A NAME=M5>add_accesses</A></H3>
|
|
|
553 |
<B>Encoding number</B>: 3<P>
|
|
|
554 |
<PRE>
|
|
|
555 |
<I>a1</I>: ACCESS
|
|
|
556 |
<I>a2</I>: ACCESS
|
|
|
557 |
-> ACCESS
|
|
|
558 |
</PRE>
|
|
|
559 |
A construction qualified with <I>add_accesses</I> has both
|
|
|
560 |
<CODE>ACCESS</CODE> properties <I>a1</I> and <I>a2</I>. This operation
|
|
|
561 |
is associative and commutative.
|
|
|
562 |
<P>
|
|
|
563 |
|
|
|
564 |
<H3>5.1.4. <A NAME=M6>constant</A></H3>
|
|
|
565 |
<B>Encoding number</B>: 4<P>
|
|
|
566 |
<PRE>
|
|
|
567 |
-> ACCESS
|
|
|
568 |
</PRE>
|
|
|
569 |
Only a variable (not an identity) may be qualified with <I>constant</I>.
|
|
|
570 |
A variable qualified with <I>constant</I> will retain its initialising
|
|
|
571 |
value unchanged throughout its lifetime.
|
|
|
572 |
<P>
|
|
|
573 |
|
|
|
574 |
<H3>5.1.5. <A NAME=M7>long_jump_access</A></H3>
|
|
|
575 |
<B>Encoding number</B>: 5<P>
|
|
|
576 |
<PRE>
|
|
|
577 |
-> ACCESS
|
|
|
578 |
</PRE>
|
|
|
579 |
An object must also have this property if it is to have a defined
|
|
|
580 |
value when a <I>long_jump</I> returns to the procedure declaring the
|
|
|
581 |
object.
|
|
|
582 |
<P>
|
|
|
583 |
|
|
|
584 |
<H3>5.1.6. <A NAME=M8>no_other_read</A></H3>
|
|
|
585 |
<B>Encoding number</B>: 6<P>
|
|
|
586 |
<PRE>
|
|
|
587 |
-> ACCESS
|
|
|
588 |
</PRE>
|
|
|
589 |
This property refers to a <CODE>POINTER</CODE>, <I>p</I>. It says
|
|
|
590 |
that, within the lifetime of the declaration being qualified, there
|
|
|
591 |
are no <I>contents</I>, <I>contents_with_mode</I> or <I>move_some</I>
|
|
|
592 |
source accesses to any pointer not derived from <I>p</I> which overlap
|
|
|
593 |
with any of the <I>contents</I>, <I>contents_with_mode</I>, <I>assign</I>,
|
|
|
594 |
<I>assign_with_mode</I> or <I>move_some</I> accesses to pointers derived
|
|
|
595 |
from <I>p</I>.
|
|
|
596 |
<P>
|
|
|
597 |
The <CODE>POINTER</CODE> being described is that obtained by applying
|
|
|
598 |
<I>obtain_tag</I> to the <CODE>TAG</CODE> of the declaration. If the
|
|
|
599 |
declaration is an <I>identity</I>, the <CODE>SHAPE</CODE> of the
|
|
|
600 |
<CODE>TAG</CODE> will be a <CODE>POINTER</CODE>.
|
|
|
601 |
<P>
|
|
|
602 |
|
|
|
603 |
<H3>5.1.7. <A NAME=M9>no_other_write</A></H3>
|
|
|
604 |
<B>Encoding number</B>: 7<P>
|
|
|
605 |
<PRE>
|
|
|
606 |
-> ACCESS
|
|
|
607 |
</PRE>
|
|
|
608 |
This property refers to a <CODE>POINTER</CODE>, <I>p</I>. It says
|
|
|
609 |
that, within the lifetime of the declaration being qualified, there
|
|
|
610 |
are no <I>assign</I>, <I>assign_with_mode</I> or <I>move_some</I>
|
|
|
611 |
destination accesses to any pointer not derived from <I>p</I> which
|
|
|
612 |
overlap with any of the <I>contents</I>, <I>contents_with_mode</I>,
|
|
|
613 |
<I>assign</I>, <I>assign_with_mode</I> or <I>move_some</I> accesses
|
|
|
614 |
to pointers derived from <I>p</I>.
|
|
|
615 |
<P>
|
|
|
616 |
The <CODE>POINTER</CODE> being described is that obtained by applying
|
|
|
617 |
<I>obtain_tag</I> to the <CODE>TAG</CODE> of the declaration. If the
|
|
|
618 |
declaration is an <I>identity</I>, the <CODE>SHAPE</CODE> of the
|
|
|
619 |
<CODE>TAG</CODE> will be a <CODE>POINTER</CODE>.
|
|
|
620 |
<P>
|
|
|
621 |
|
|
|
622 |
<H3>5.1.8. <A NAME=M10>out_par</A></H3>
|
|
|
623 |
<B>Encoding number</B>: 8<P>
|
|
|
624 |
<PRE>
|
|
|
625 |
-> ACCESS
|
|
|
626 |
</PRE>
|
|
|
627 |
An object qualified by <I>out_par</I> will be an output parameter
|
|
|
628 |
in a <I>make_general_proc</I> construct. This will indicate that the
|
|
|
629 |
final value of the parameter is required in <I>postlude</I> part of
|
|
|
630 |
an <I>apply_general_proc</I> of this procedure.
|
|
|
631 |
<P>
|
|
|
632 |
|
|
|
633 |
<H3>5.1.9. <A NAME=M11>preserve</A></H3>
|
|
|
634 |
<B>Encoding number</B>: 9<P>
|
|
|
635 |
<PRE>
|
|
|
636 |
-> ACCESS
|
|
|
637 |
</PRE>
|
|
|
638 |
This property refers to a global object. It says that the object will
|
|
|
639 |
be included in the final program, whether or not all possible accesses
|
|
|
640 |
to that object are optimised away; for example by inlining all possible
|
|
|
641 |
uses of procedure object.
|
|
|
642 |
<P>
|
|
|
643 |
|
|
|
644 |
<H3>5.1.10. <A NAME=M12>register</A></H3>
|
|
|
645 |
<B>Encoding number</B>: 10<P>
|
|
|
646 |
<PRE>
|
|
|
647 |
-> ACCESS
|
|
|
648 |
</PRE>
|
|
|
649 |
Indicates that an object with this property is frequently used. This
|
|
|
650 |
can be taken as a recommendation to place it in a register.
|
|
|
651 |
<P>
|
|
|
652 |
|
|
|
653 |
<H3>5.1.11. <A NAME=M13>standard_access</A></H3>
|
|
|
654 |
<B>Encoding number</B>: 11<P>
|
|
|
655 |
<PRE>
|
|
|
656 |
-> ACCESS
|
|
|
657 |
</PRE>
|
|
|
658 |
An object qualified as having <I>standard_access</I> has normal (i.e.
|
|
|
659 |
no special) access properties.
|
|
|
660 |
<P>
|
|
|
661 |
|
|
|
662 |
<H3>5.1.12. <A NAME=M14>used_as_volatile</A></H3>
|
|
|
663 |
<B>Encoding number</B>: 12<P>
|
|
|
664 |
<PRE>
|
|
|
665 |
-> ACCESS
|
|
|
666 |
</PRE>
|
|
|
667 |
An object qualified as having <I>used_as_volatile</I> will be used
|
|
|
668 |
in a
|
|
|
669 |
<I>move_some</I>, <I>contents_with_mode</I> or an
|
|
|
670 |
<I>assign_with_mode</I> construct with <CODE>TRANSFER_MODE</CODE>
|
|
|
671 |
<I>volatile</I>.
|
|
|
672 |
<P>
|
|
|
673 |
|
|
|
674 |
<H3>5.1.13. <A NAME=M15>visible</A></H3>
|
|
|
675 |
<B>Encoding number</B>: 13<P>
|
|
|
676 |
<PRE>
|
|
|
677 |
-> ACCESS
|
|
|
678 |
</PRE>
|
|
|
679 |
An object qualified as <I>visible</I> may be accessed when the procedure
|
|
|
680 |
in which it is declared is not the current procedure. A <CODE>TAG</CODE>
|
|
|
681 |
must have this property if it is to be used by <I>env_offset</I>.
|
|
|
682 |
<P>
|
|
|
683 |
|
|
|
684 |
<HR>
|
|
|
685 |
<H2>5.2. <A NAME=M297>AL_TAG</A></H2>
|
|
|
686 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
687 |
<B>Is coding extendable</B>: yes<BR>
|
|
|
688 |
<B>Linkable entity identification</B>: <I>alignment</I><P>
|
|
|
689 |
<CODE>AL_TAG</CODE>s name <CODE>ALIGNMENT</CODE>s. They are used so
|
|
|
690 |
that circular definitions can be written in TDF. However, because
|
|
|
691 |
of the definition of alignments, intrinsic circularities cannot occur.
|
|
|
692 |
<P>
|
|
|
693 |
<I>For example, the following equation has a circular form</I>
|
|
|
694 |
<I>x = alignment(pointer(alignment(x))) and it or a similar equation
|
|
|
695 |
might occur in TDF. But since
|
|
|
696 |
</I><I>alignment</I>(<I>pointer</I>(<I>x</I>)) is {<I>pointer</I>},
|
|
|
697 |
this reduces to <I>x</I> = {<I>pointer</I>}.
|
|
|
698 |
<H3>5.2.1. <A NAME=M17>al_tag_apply_token</A></H3>
|
|
|
699 |
<B>Encoding number</B>: 2<P>
|
|
|
700 |
<PRE>
|
|
|
701 |
<I>token_value</I>: TOKEN
|
|
|
702 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
703 |
-> AL_TAG
|
|
|
704 |
</PRE>
|
|
|
705 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
706 |
<I>token_args</I> to give an <CODE>AL_TAG</CODE>.
|
|
|
707 |
<P>
|
|
|
708 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
709 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
710 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
711 |
<P>
|
|
|
712 |
|
|
|
713 |
<H3>5.2.2. <A NAME=M18>make_al_tag</A></H3>
|
|
|
714 |
<B>Encoding number</B>: 1<P>
|
|
|
715 |
<PRE>
|
|
|
716 |
<I>al_tagno</I>: TDFINT
|
|
|
717 |
-> AL_TAG
|
|
|
718 |
</PRE>
|
|
|
719 |
<I>make_al_tag</I> constructs an <CODE>AL_TAG</CODE> identified by
|
|
|
720 |
<I>al_tagno</I>.
|
|
|
721 |
<P>
|
|
|
722 |
|
|
|
723 |
<HR>
|
|
|
724 |
<H2>5.3. <A NAME=M19>AL_TAGDEF</A></H2>
|
|
|
725 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
726 |
<B>Is coding extendable</B>: yes<P>
|
|
|
727 |
An <CODE>AL_TAGDEF</CODE> gives the definition of an <CODE>AL_TAG</CODE>
|
|
|
728 |
for incorporation into a <CODE>AL_TAGDEF_PROPS</CODE>.
|
|
|
729 |
<P>
|
|
|
730 |
|
|
|
731 |
<H3>5.3.1. <A NAME=M20>make_al_tagdef</A></H3>
|
|
|
732 |
<B>Encoding number</B>: 1<P>
|
|
|
733 |
<PRE>
|
|
|
734 |
<I>t</I>: TDFINT
|
|
|
735 |
<I>a</I>: ALIGNMENT
|
|
|
736 |
-> AL_TAGDEF
|
|
|
737 |
</PRE>
|
|
|
738 |
The <CODE>AL_TAG</CODE> identified by <I>t</I> is defined to stand
|
|
|
739 |
for the <CODE>ALIGNMENT</CODE> <I>a</I>. All the <CODE>AL_TAGDEF</CODE>s
|
|
|
740 |
in a <CODE>CAPSULE</CODE> must be considered together as a set of
|
|
|
741 |
simultaneous equations defining <CODE>ALIGNMENT</CODE> values for
|
|
|
742 |
the <CODE>AL_TAG</CODE>s. No order is imposed on the definitions.
|
|
|
743 |
<P>
|
|
|
744 |
In any particular <CODE>CAPSULE</CODE> the set of equations may be
|
|
|
745 |
incomplete, but a <CODE>CAPSULE</CODE> which is being translated into
|
|
|
746 |
code will have a set of equations which defines all the
|
|
|
747 |
<CODE>AL_TAG</CODE>s which it uses.
|
|
|
748 |
<P>
|
|
|
749 |
The result of the evaluation of the <I>control</I> argument of any
|
|
|
750 |
<I>x_cond</I> construction (e.g <I>alignment_cond</I>) used in <I>a</I>
|
|
|
751 |
shall be independent of any <CODE>AL_TAG</CODE>s used in the
|
|
|
752 |
<I>control</I>. Simultaneous equations defining <CODE>ALIGNMENT</CODE>s
|
|
|
753 |
can then always be solved.
|
|
|
754 |
<P>
|
|
|
755 |
See <A HREF="spec10.html#32">Circular types in languages</A>.
|
|
|
756 |
<P>
|
|
|
757 |
|
|
|
758 |
<HR>
|
|
|
759 |
<H2>5.4. <A NAME=M21>AL_TAGDEF_PROPS</A></H2>
|
|
|
760 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
761 |
<B>Is coding extendable</B>: no<BR>
|
|
|
762 |
<B>Unit identification</B>: <I>aldef</I><P>
|
|
|
763 |
|
|
|
764 |
<H3>5.4.1. <A NAME=M22>make_al_tagdefs</A></H3>
|
|
|
765 |
<B>Encoding number</B>: 0<P>
|
|
|
766 |
<PRE>
|
|
|
767 |
<I>no_labels</I>: TDFINT
|
|
|
768 |
<I>tds</I>: SLIST(AL_TAGDEF)
|
|
|
769 |
-> AL_TAGDEF_PROPS
|
|
|
770 |
</PRE>
|
|
|
771 |
<I>no_labels</I> is the number of local <CODE>LABEL</CODE>s used in
|
|
|
772 |
<I>tds</I>. <I>tds</I> is a list of <CODE>AL_TAGDEF</CODE>s which
|
|
|
773 |
define the bindings for <I>al_tags</I>.
|
|
|
774 |
<P>
|
|
|
775 |
|
|
|
776 |
<HR>
|
|
|
777 |
<H2>5.5. <A NAME=M26>ALIGNMENT</A></H2>
|
|
|
778 |
<B>Number of encoding bits</B>: 4<BR>
|
|
|
779 |
<B>Is coding extendable</B>: yes<P>
|
|
|
780 |
An <CODE>ALIGNMENT</CODE> gives information about the layout of data
|
|
|
781 |
in memory and hence is a parameter for the <CODE>POINTER</CODE> and
|
|
|
782 |
<CODE>OFFSET SHAPE</CODE>s (see <A HREF="spec10.html#26">Memory Model</A>).
|
|
|
783 |
This information consists of a set of elements.
|
|
|
784 |
<P>
|
|
|
785 |
The possible values of the elements in such a set are <I>proc</I>,
|
|
|
786 |
<I>code</I>, <I>pointer</I>, <I>offset</I>, all <CODE>VARIETY</CODE>s,
|
|
|
787 |
all <CODE>FLOATING_VARIETY</CODE>s and all
|
|
|
788 |
<CODE>BITFIELD_VARIETY</CODE>s. The sets are written here as, for
|
|
|
789 |
example, {<I>pointer</I>, <I>proc</I>} meaning the set containing
|
|
|
790 |
<I>pointer</I> and <I>proc</I>.
|
|
|
791 |
<P>
|
|
|
792 |
In addition, there are "special" <CODE>ALIGNMENT</CODE>s
|
|
|
793 |
<I>alloca_alignment</I>, <I>callers_alignment</I>,
|
|
|
794 |
<I>callees_alignment</I>, <I>locals_alignment</I> and
|
|
|
795 |
<I>var_param_alignment</I>. Each of these are considered to be sets
|
|
|
796 |
which include all of the "ordinary" <CODE>ALIGNMENT</CODE>s
|
|
|
797 |
above.
|
|
|
798 |
<P>
|
|
|
799 |
There is a function, <I>alignment</I>, which can be applied to a
|
|
|
800 |
<CODE>SHAPE</CODE> to give an <CODE>ALIGNMENT</CODE> (see the definition
|
|
|
801 |
below). The interpretation of a <CODE>POINTER</CODE> to an
|
|
|
802 |
<CODE>ALIGNMENT</CODE>, <I>a</I>, is that it can serve as a
|
|
|
803 |
<CODE>POINTER</CODE> to any <CODE>SHAPE</CODE>, <I>s</I>, such that
|
|
|
804 |
<I>alignment</I>(<I>s</I>) is a subset of the set <I>a</I>.
|
|
|
805 |
<P>
|
|
|
806 |
So given a <CODE>POINTER</CODE>({<I>proc</I>, <I>pointer</I>}) it
|
|
|
807 |
is permitted to assign a <CODE>PROC</CODE> or a <CODE>POINTER</CODE>
|
|
|
808 |
to it, or indeed a compound containing only <CODE>PROC</CODE>s and
|
|
|
809 |
<CODE>POINTER</CODE>s. This permission is valid only in respect of
|
|
|
810 |
the space being of the right kind; it may or may not be big enough
|
|
|
811 |
for the data.
|
|
|
812 |
<P>
|
|
|
813 |
The most usual use for <CODE>ALIGNMENT</CODE> is to ensure that addresses
|
|
|
814 |
of <I>int</I> values are aligned on 4-byte boundaries, <I>float</I>
|
|
|
815 |
values are aligned on 4-byte boundaries, <I>double</I>s on 8-bit boundaries
|
|
|
816 |
etc. and whatever may be implied by the definitions of the machines
|
|
|
817 |
and languages involved.
|
|
|
818 |
<P>
|
|
|
819 |
In the specification the phrase "<I>a</I> will include <I>b</I>"
|
|
|
820 |
where <I>a</I> and <I>b</I> are <CODE>ALIGNMENT</CODE>s, means that
|
|
|
821 |
the set <I>b</I> will be a subset of <I>a</I> (or equal to <I>a</I>).
|
|
|
822 |
<P>
|
|
|
823 |
|
|
|
824 |
<H3>5.5.1. <A NAME=M24>alignment_apply_token</A></H3>
|
|
|
825 |
<B>Encoding number</B>: 1<P>
|
|
|
826 |
<PRE>
|
|
|
827 |
<I>token_value</I>: TOKEN
|
|
|
828 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
829 |
-> ALIGNMENT
|
|
|
830 |
</PRE>
|
|
|
831 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
832 |
<I>token_args</I> to give an <CODE>ALIGNMENT</CODE>.
|
|
|
833 |
<P>
|
|
|
834 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
835 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
836 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
837 |
<P>
|
|
|
838 |
|
|
|
839 |
<H3>5.5.2. <A NAME=M25>alignment_cond</A></H3>
|
|
|
840 |
<B>Encoding number</B>: 2<P>
|
|
|
841 |
<PRE>
|
|
|
842 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
843 |
<I>e1</I>: BITSTREAM ALIGNMENT
|
|
|
844 |
<I>e2</I>: BITSTREAM ALIGNMENT
|
|
|
845 |
-> ALIGNMENT
|
|
|
846 |
</PRE>
|
|
|
847 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
848 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
849 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
850 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
851 |
and <I>e1</I> is ignored and never processed.
|
|
|
852 |
<P>
|
|
|
853 |
|
|
|
854 |
<H3>5.5.3. <A NAME=M26A>alignment</A></H3>
|
|
|
855 |
<B>Encoding number</B>: 3<P>
|
|
|
856 |
<PRE>
|
|
|
857 |
<I>sha</I>: SHAPE
|
|
|
858 |
-> ALIGNMENT
|
|
|
859 |
</PRE>
|
|
|
860 |
The <I>alignment</I> construct is defined as follows:
|
|
|
861 |
<UL>
|
|
|
862 |
<LI>If <I>sha</I> is <CODE>PROC</CODE> then the resulting
|
|
|
863 |
<CODE>ALIGNMENT</CODE> is {<I>proc</I>}.
|
|
|
864 |
<LI>If <I>sha</I> is <CODE>INTEGER</CODE>(<I>v</I>) then the resulting
|
|
|
865 |
<CODE>ALIGNMENT</CODE> is {<I>v</I>}.
|
|
|
866 |
<LI>If <I>sha</I> is <CODE>FLOATING</CODE>(<I>v</I>) then the resulting
|
|
|
867 |
<CODE>ALIGNMENT</CODE> is {<I>v</I>}.
|
|
|
868 |
<LI>If <I>sha</I> is <CODE>BITFIELD</CODE>(<I>v</I>) then the resulting
|
|
|
869 |
<CODE>ALIGNMENT</CODE> is {<I>v</I>}.
|
|
|
870 |
<LI>If <I>sha</I> is <CODE>TOP</CODE> the resulting <CODE>ALIGNMENT</CODE>
|
|
|
871 |
is {} - the empty set.
|
|
|
872 |
<LI>If <I>sha</I> is <CODE>BOTTOM</CODE> the resulting <CODE>ALIGNMENT</CODE>
|
|
|
873 |
is undefined.
|
|
|
874 |
<LI>If <I>sha</I> is <CODE>POINTER</CODE>(<I>x</I>) the resulting
|
|
|
875 |
<CODE>ALIGNMENT</CODE> is {<I>pointer</I>}.
|
|
|
876 |
<LI>If <I>sha</I> is <CODE>OFFSET</CODE>(<I>x</I>, <I>y</I>) the resulting
|
|
|
877 |
<CODE>ALIGNMENT</CODE> is {<I>offset</I>}.
|
|
|
878 |
<LI>If <I>sha</I> is <CODE>NOF</CODE>(<I>n</I>, <I>s</I>) the resulting
|
|
|
879 |
<CODE>ALIGNMENT</CODE> is <I>alignment</I>(<I>s</I>).
|
|
|
880 |
<LI>If <I>sha</I> is <CODE>COMPOUND</CODE>(<CODE>EXP OFFSET</CODE>(<I>x</I>,
|
|
|
881 |
<I>y</I>)) then the resulting <CODE>ALIGNMENT</CODE> is <I>x</I>.
|
|
|
882 |
</UL>
|
|
|
883 |
<P>
|
|
|
884 |
|
|
|
885 |
<H3>5.5.4. <A NAME=M27>alloca_alignment</A></H3>
|
|
|
886 |
<B>Encoding number</B>: 4<P>
|
|
|
887 |
<PRE>
|
|
|
888 |
-> ALIGNMENT
|
|
|
889 |
</PRE>
|
|
|
890 |
Delivers the <CODE>ALIGNMENT</CODE> of <CODE>POINTER</CODE>s produced
|
|
|
891 |
from <I>local_alloc</I>.
|
|
|
892 |
<P>
|
|
|
893 |
|
|
|
894 |
<H3>5.5.5. <A NAME=M28>callees_alignment</A></H3>
|
|
|
895 |
<B>Encoding number</B>: 5<P>
|
|
|
896 |
<PRE>
|
|
|
897 |
<I>var</I>: BOOL
|
|
|
898 |
-> ALIGNMENT
|
|
|
899 |
</PRE>
|
|
|
900 |
If <I>var</I> is <I>true</I> the <CODE>ALIGNMENT</CODE> is that of
|
|
|
901 |
callee parameters qualified by the <CODE>PROCPROPS</CODE>
|
|
|
902 |
<I>var_callees</I>. If <I>var</I> is <I>false</I>, the
|
|
|
903 |
<CODE>ALIGNMENT</CODE> is that of callee parameters not qualified
|
|
|
904 |
by
|
|
|
905 |
<CODE>PROCPROPS</CODE> <I>var_callees</I>.
|
|
|
906 |
<P>
|
|
|
907 |
Delivers the <CODE>base ALIGNMENT</CODE> of <CODE>OFFSET</CODE>s from
|
|
|
908 |
a frame-pointer to a <CODE>CALLEE</CODE> parameter. Values of such
|
|
|
909 |
<CODE>OFFSET</CODE>s can only be produced by <I>env_offset</I> applied
|
|
|
910 |
to <CODE>CALLEE</CODE> parameters, or offset arithmetic operations
|
|
|
911 |
applied to existing <CODE>OFFSET</CODE>s.
|
|
|
912 |
<P>
|
|
|
913 |
|
|
|
914 |
<H3>5.5.6. <A NAME=M29>callers_alignment</A></H3>
|
|
|
915 |
<B>Encoding number</B>: 6<P>
|
|
|
916 |
<PRE>
|
|
|
917 |
<I>var</I>: BOOL
|
|
|
918 |
-> ALIGNMENT
|
|
|
919 |
</PRE>
|
|
|
920 |
If <I>var</I> is <I>true</I> the <CODE>ALIGNMENT</CODE> is that of
|
|
|
921 |
caller parameters qualified by the <CODE>PROCPROPS</CODE>
|
|
|
922 |
<I>var_callers</I>. If <I>var</I> is <I>false</I>, the
|
|
|
923 |
<CODE>ALIGNMENT</CODE> is that of caller parameters not qualified
|
|
|
924 |
by
|
|
|
925 |
<CODE>PROCPROPS</CODE> <I>var_callers</I>.
|
|
|
926 |
<P>
|
|
|
927 |
Delivers the <CODE>base ALIGNMENT</CODE> of <CODE>OFFSET</CODE>s from
|
|
|
928 |
a frame-pointer to a <CODE>CALLER</CODE> parameter. Values of such
|
|
|
929 |
<CODE>OFFSET</CODE>s can only be produced by <I>env_offset</I> applied
|
|
|
930 |
to <CODE>CALLER</CODE> parameters, or offset arithmetic operations
|
|
|
931 |
applied to existing <CODE>OFFSET</CODE>s.
|
|
|
932 |
<P>
|
|
|
933 |
|
|
|
934 |
<H3>5.5.7. <A NAME=M30>code_alignment</A></H3>
|
|
|
935 |
<B>Encoding number</B>: 7<P>
|
|
|
936 |
<PRE>
|
|
|
937 |
-> ALIGNMENT
|
|
|
938 |
</PRE>
|
|
|
939 |
Delivers {<I>code</I>}, the <CODE>ALIGNMENT</CODE> of the
|
|
|
940 |
<CODE>POINTER</CODE> produced by <I>make_local_lv</I>.
|
|
|
941 |
<P>
|
|
|
942 |
|
|
|
943 |
<H3>5.5.8. <A NAME=M31>locals_alignment</A></H3>
|
|
|
944 |
<B>Encoding number</B>: 8<P>
|
|
|
945 |
<PRE>
|
|
|
946 |
-> ALIGNMENT
|
|
|
947 |
</PRE>
|
|
|
948 |
Delivers the <CODE>base ALIGNMENT</CODE> of <CODE>OFFSET</CODE>s from
|
|
|
949 |
a frame-pointer to a value defined by <I>variable</I> or <I>identify</I>.
|
|
|
950 |
Values of such <CODE>OFFSET</CODE>s can only be produced by
|
|
|
951 |
<I>env_offset</I> applied to <CODE>TAG</CODE>s so defined, or offset
|
|
|
952 |
arithmetic operations applied to existing <CODE>OFFSET</CODE>s.
|
|
|
953 |
<P>
|
|
|
954 |
|
|
|
955 |
<H3>5.5.9. <A NAME=M32>obtain_al_tag</A></H3>
|
|
|
956 |
<B>Encoding number</B>: 9<P>
|
|
|
957 |
<PRE>
|
|
|
958 |
<I>at</I>: AL_TAG
|
|
|
959 |
-> ALIGNMENT
|
|
|
960 |
</PRE>
|
|
|
961 |
<I>obtain_al_tag</I> produces the <CODE>ALIGNMENT</CODE> with which
|
|
|
962 |
the <CODE>AL_TAG</CODE> <I>at</I> is bound.
|
|
|
963 |
<P>
|
|
|
964 |
<P>
|
|
|
965 |
|
|
|
966 |
<H3>5.5.10. <A NAME=M33>parameter_alignment</A></H3>
|
|
|
967 |
<B>Encoding number</B>: 10<P>
|
|
|
968 |
<PRE>
|
|
|
969 |
<I>sha</I>: SHAPE
|
|
|
970 |
-> ALIGNMENT
|
|
|
971 |
</PRE>
|
|
|
972 |
Delivers the <CODE>ALIGNMENT</CODE> of a parameter of a procedure
|
|
|
973 |
of <CODE>SHAPE</CODE> <I>sha</I>.
|
|
|
974 |
<P>
|
|
|
975 |
|
|
|
976 |
<H3>5.5.11. <A NAME=M34>unite_alignments</A></H3>
|
|
|
977 |
<B>Encoding number</B>: 11<P>
|
|
|
978 |
<PRE>
|
|
|
979 |
<I>a1</I>: ALIGNMENT
|
|
|
980 |
<I>a2</I>: ALIGNMENT
|
|
|
981 |
-> ALIGNMENT
|
|
|
982 |
</PRE>
|
|
|
983 |
<I>unite_alignments</I> produces the alignment at which all the members
|
|
|
984 |
of the <CODE>ALIGNMENT</CODE> sets <I>a1</I> and <I>a2</I> can be
|
|
|
985 |
placed - in other words the <CODE>ALIGNMENT</CODE> set which is the
|
|
|
986 |
union of <I>a1</I> and <I>a2</I>.
|
|
|
987 |
<P>
|
|
|
988 |
|
|
|
989 |
<H3>5.5.12. <A NAME=M35>var_param_alignment</A></H3>
|
|
|
990 |
<B>Encoding number</B>: 12<P>
|
|
|
991 |
<PRE>
|
|
|
992 |
-> ALIGNMENT
|
|
|
993 |
</PRE>
|
|
|
994 |
Delivers the <CODE>ALIGNMENT</CODE> used in the <I>var_param</I> argument
|
|
|
995 |
of <I>make_proc</I>.
|
|
|
996 |
<P>
|
|
|
997 |
|
|
|
998 |
<HR>
|
|
|
999 |
<H2>5.6. <A NAME=M299>BITFIELD_VARIETY</A></H2>
|
|
|
1000 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
1001 |
<B>Is coding extendable</B>: yes<P>
|
|
|
1002 |
These describe runtime bitfield values. The intention is that these
|
|
|
1003 |
values are usually kept in memory locations which need not be aligned
|
|
|
1004 |
on addressing boundaries.
|
|
|
1005 |
<P>
|
|
|
1006 |
There is no limit on the size of bitfield values in TDF, but an installer
|
|
|
1007 |
may specify limits. See <A HREF="spec10.html#66">Representing bitfields</A>
|
|
|
1008 |
and <A HREF="spec10.html#68">Permitted limits</A>.
|
|
|
1009 |
<P>
|
|
|
1010 |
|
|
|
1011 |
<H3>5.6.1. <A NAME=M37>bfvar_apply_token</A></H3>
|
|
|
1012 |
<B>Encoding number</B>: 1<P>
|
|
|
1013 |
<PRE>
|
|
|
1014 |
<I>token_value</I>: TOKEN
|
|
|
1015 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
1016 |
-> BITFIELD_VARIETY
|
|
|
1017 |
</PRE>
|
|
|
1018 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
1019 |
<I>token_args</I> to give a <CODE>BITFIELD_VARIETY</CODE>.
|
|
|
1020 |
<P>
|
|
|
1021 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
1022 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
1023 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
1024 |
<P>
|
|
|
1025 |
|
|
|
1026 |
<H3>5.6.2. <A NAME=M38>bfvar_cond</A></H3>
|
|
|
1027 |
<B>Encoding number</B>: 2<P>
|
|
|
1028 |
<PRE>
|
|
|
1029 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
1030 |
<I>e1</I>: BITSTREAM BITFIELD_VARIETY
|
|
|
1031 |
<I>e2</I>: BITSTREAM BITFIELD_VARIETY
|
|
|
1032 |
-> BITFIELD_VARIETY
|
|
|
1033 |
</PRE>
|
|
|
1034 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
1035 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
1036 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
1037 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
1038 |
and <I>e1</I> is ignored and never processed.
|
|
|
1039 |
<P>
|
|
|
1040 |
|
|
|
1041 |
<H3>5.6.3. <A NAME=M39>bfvar_bits</A></H3>
|
|
|
1042 |
<B>Encoding number</B>: 3<P>
|
|
|
1043 |
<PRE>
|
|
|
1044 |
<I>issigned</I>: BOOL
|
|
|
1045 |
<I>bits</I>: NAT
|
|
|
1046 |
-> BITFIELD_VARIETY
|
|
|
1047 |
</PRE>
|
|
|
1048 |
<I>bfvar_bits</I> constructs a <CODE>BITFIELD_VARIETY</CODE> describing
|
|
|
1049 |
a pattern of <I>bits</I> bits. If <I>issigned</I> is <I>true</I>,
|
|
|
1050 |
the pattern is considered to be a twos-complement signed number: otherwise
|
|
|
1051 |
it is considered to be unsigned.
|
|
|
1052 |
<P>
|
|
|
1053 |
|
|
|
1054 |
<HR>
|
|
|
1055 |
<H2>5.7. <A NAME=M40>BITSTREAM</A></H2>
|
|
|
1056 |
A <CODE>BITSTREAM</CODE> consists of an encoding of any number of
|
|
|
1057 |
bits. This encoding is such that any program reading TDF can determine
|
|
|
1058 |
how to skip over it. To read it meaningfully extra knowledge of what
|
|
|
1059 |
it represents may be needed.
|
|
|
1060 |
<P>
|
|
|
1061 |
A <CODE>BITSTREAM</CODE> is used, for example, to supply parameters
|
|
|
1062 |
in a <CODE>TOKEN</CODE> application. If there is a definition of this
|
|
|
1063 |
<CODE>TOKEN</CODE> available, this will provide the information needed
|
|
|
1064 |
to decode the bitstream.
|
|
|
1065 |
<P>
|
|
|
1066 |
See <A HREF="spec11.html#17">The TDF encoding</A>.
|
|
|
1067 |
<P>
|
|
|
1068 |
|
|
|
1069 |
<HR>
|
|
|
1070 |
<H2>5.8. <A NAME=M300>BOOL</A></H2>
|
|
|
1071 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
1072 |
<B>Is coding extendable</B>: yes<P>
|
|
|
1073 |
A <CODE>BOOL</CODE> is a piece of TDF which can take two values,
|
|
|
1074 |
<I>true</I> or <I>false</I>.
|
|
|
1075 |
<P>
|
|
|
1076 |
|
|
|
1077 |
<H3>5.8.1. <A NAME=M42>bool_apply_token</A></H3>
|
|
|
1078 |
<B>Encoding number</B>: 1<P>
|
|
|
1079 |
<PRE>
|
|
|
1080 |
<I>token_value</I>: TOKEN
|
|
|
1081 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
1082 |
-> BOOL
|
|
|
1083 |
</PRE>
|
|
|
1084 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
1085 |
<I>token_args</I> to give a <CODE>BOOL</CODE>.
|
|
|
1086 |
<P>
|
|
|
1087 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
1088 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
1089 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
1090 |
<P>
|
|
|
1091 |
|
|
|
1092 |
<H3>5.8.2. <A NAME=M43>bool_cond</A></H3>
|
|
|
1093 |
<B>Encoding number</B>: 2<P>
|
|
|
1094 |
<PRE>
|
|
|
1095 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
1096 |
<I>e1</I>: BITSTREAM BOOL
|
|
|
1097 |
<I>e2</I>: BITSTREAM BOOL
|
|
|
1098 |
-> BOOL
|
|
|
1099 |
</PRE>
|
|
|
1100 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
1101 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
1102 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
1103 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
1104 |
and <I>e1</I> is ignored and never processed.
|
|
|
1105 |
<P>
|
|
|
1106 |
|
|
|
1107 |
<H3>5.8.3. <A NAME=M44>false</A></H3>
|
|
|
1108 |
<B>Encoding number</B>: 3<P>
|
|
|
1109 |
<PRE>
|
|
|
1110 |
-> BOOL
|
|
|
1111 |
</PRE>
|
|
|
1112 |
<I>false</I> produces a false <CODE>BOOL</CODE>.
|
|
|
1113 |
<P>
|
|
|
1114 |
|
|
|
1115 |
<H3>5.8.4. <A NAME=M45>true</A></H3>
|
|
|
1116 |
<B>Encoding number</B>: 4<P>
|
|
|
1117 |
<PRE>
|
|
|
1118 |
-> BOOL
|
|
|
1119 |
</PRE>
|
|
|
1120 |
<I>true</I> produces a true <CODE>BOOL</CODE>.
|
|
|
1121 |
<P>
|
|
|
1122 |
|
|
|
1123 |
<HR>
|
|
|
1124 |
<H2>5.9. <A NAME=M46>BYTESTREAM</A></H2>
|
|
|
1125 |
A <CODE>BYTESTREAM</CODE> is analogous to a <CODE>BITSTREAM</CODE>,
|
|
|
1126 |
but is encoded to permit fast copying.
|
|
|
1127 |
<P>
|
|
|
1128 |
See <A HREF="spec11.html#17">The TDF encoding</A>.
|
|
|
1129 |
<P>
|
|
|
1130 |
|
|
|
1131 |
<HR>
|
|
|
1132 |
<H2>5.10. <A NAME=M47>CALLEES</A></H2>
|
|
|
1133 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
1134 |
<B>Is coding extendable</B>: yes<P>
|
|
|
1135 |
This is an auxilliary <CODE>SORT</CODE> used in calling procedures
|
|
|
1136 |
by
|
|
|
1137 |
<I>apply_general_proc</I> and <I>tail_call</I> to provide their actual
|
|
|
1138 |
callee parameters.
|
|
|
1139 |
<P>
|
|
|
1140 |
|
|
|
1141 |
<H3>5.10.1. <A NAME=M48>make_callee_list</A></H3>
|
|
|
1142 |
<B>Encoding number</B>: 1<P>
|
|
|
1143 |
<PRE>
|
|
|
1144 |
<I>args</I>: LIST(EXP)
|
|
|
1145 |
-> CALLEES
|
|
|
1146 |
</PRE>
|
|
|
1147 |
The list of <CODE>EXP</CODE>s <I>args</I> are evaluated in any interleaved
|
|
|
1148 |
order and the resulting list of values form the actual callee parameters
|
|
|
1149 |
of the call.
|
|
|
1150 |
<P>
|
|
|
1151 |
|
|
|
1152 |
<H3>5.10.2. <A NAME=M49>make_dynamic_callees</A></H3>
|
|
|
1153 |
<B>Encoding number</B>: 2<P>
|
|
|
1154 |
<PRE>
|
|
|
1155 |
<I>ptr</I>: EXP POINTER(<I>x</I>)
|
|
|
1156 |
<I>sze</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
1157 |
-> CALLEES
|
|
|
1158 |
</PRE>
|
|
|
1159 |
The value of size <I>sze</I> pointed at by <I>ptr</I> forms the actual
|
|
|
1160 |
callee parameters of the call.
|
|
|
1161 |
<P>
|
|
|
1162 |
The <CODE>CALLEES</CODE> value is intended to refer to a sequence
|
|
|
1163 |
of zero or more callee parameters. <I>x</I> will include
|
|
|
1164 |
<I>parameter_alignment</I>(<I>s</I>) for each <I>s</I> that is the
|
|
|
1165 |
<CODE>SHAPE</CODE> of an intended callee parameter. The value addressed
|
|
|
1166 |
by <I>ptr</I> may be produced in one of two ways. It may be produced
|
|
|
1167 |
as a <CODE>COMPOUND SHAPE</CODE> value in the normal sense of a structure,
|
|
|
1168 |
whose successive elements will be used to generate the sequence of
|
|
|
1169 |
callee parameters. In this case, each element in the sequence of
|
|
|
1170 |
<CODE>SHAPE</CODE> <I>s</I> must additionally be padded to
|
|
|
1171 |
<I>parameter_alignment</I>(<I>s</I>). Alternatively, <I>ptr</I> may
|
|
|
1172 |
address the callee parameters of an already activated procedure, by
|
|
|
1173 |
referring to the first of the sequence. <I>sze</I> will be equivalent
|
|
|
1174 |
to <I>shape_offset</I>(<I>c</I>) where <I>c</I> is the <CODE>COMPOUND
|
|
|
1175 |
SHAPE</CODE> just described.
|
|
|
1176 |
<P>
|
|
|
1177 |
The call involved (i.e. <I>apply_general_proc</I> or <I>tail_call</I>)
|
|
|
1178 |
must have a <I>var_callees</I> <CODE>PROCPROPS</CODE>.
|
|
|
1179 |
<P>
|
|
|
1180 |
|
|
|
1181 |
<H3>5.10.3. <A NAME=M50>same_callees</A></H3>
|
|
|
1182 |
<B>Encoding number</B>: 3<P>
|
|
|
1183 |
<PRE>
|
|
|
1184 |
-> CALLEES
|
|
|
1185 |
</PRE>
|
|
|
1186 |
The callee parameters of the call are the same as those of the current
|
|
|
1187 |
procedure.
|
|
|
1188 |
<P>
|
|
|
1189 |
<P>
|
|
|
1190 |
|
|
|
1191 |
<HR>
|
|
|
1192 |
<H2>5.11. <A NAME=M51>CAPSULE</A></H2>
|
|
|
1193 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
1194 |
<B>Is coding extendable</B>: no<P>
|
|
|
1195 |
A <CODE>CAPSULE</CODE> is an independent piece of TDF. There is only
|
|
|
1196 |
one construction, <I>make_capsule</I>.
|
|
|
1197 |
<P>
|
|
|
1198 |
|
|
|
1199 |
<H3>5.11.1. <A NAME=M53>make_capsule</A></H3>
|
|
|
1200 |
<!-- BREAK 2 -->
|
|
|
1201 |
<B>Encoding number</B>: 0<P>
|
|
|
1202 |
<PRE>
|
|
|
1203 |
<I>prop_names</I>: SLIST(TDFIDENT)
|
|
|
1204 |
<I>cap_linking</I>: SLIST(CAPSULE_LINK)
|
|
|
1205 |
<I>ext_linkage</I>: SLIST(EXTERN_LINK)
|
|
|
1206 |
<I>groups</I>: SLIST(GROUP)
|
|
|
1207 |
-> CAPSULE
|
|
|
1208 |
</PRE>
|
|
|
1209 |
<I>make_capsule</I> brings together <CODE>UNIT</CODE>s and linking
|
|
|
1210 |
and naming information. See <A HREF="spec5.html#2">The Overall Structure</A>.
|
|
|
1211 |
<P>
|
|
|
1212 |
The elements of the list, <I>prop_names</I>, correspond one-to-one
|
|
|
1213 |
with the elements of the list, <I>groups</I>. The element of
|
|
|
1214 |
<I>prop_names</I> is the unit identification of all the
|
|
|
1215 |
<CODE>UNIT</CODE>s in the corresponding <CODE>GROUP</CODE>. See
|
|
|
1216 |
<A HREF="#M266"><CODE>PROPS</CODE></A>. A <CODE>CAPSULE</CODE> need
|
|
|
1217 |
not contain all the kinds of <CODE>UNIT</CODE>.
|
|
|
1218 |
<P>
|
|
|
1219 |
It is intended that new kinds of <CODE>PROPS</CODE> with new unit
|
|
|
1220 |
identifications can be added to the standard in a purely additive
|
|
|
1221 |
fashion, either to form a new standard or for private purposes.
|
|
|
1222 |
<P>
|
|
|
1223 |
The elements of the list, <I>cap_linking</I>, correspond one-to-one
|
|
|
1224 |
with the elements of the list, <I>ext_linkage</I>. The element of
|
|
|
1225 |
<I>cap_linking</I> gives the linkable entity identification for all
|
|
|
1226 |
the <CODE>LINKEXTERN</CODE>s in the element of <I>ext_linkage</I>.
|
|
|
1227 |
It also gives the number of <CODE>CAPSULE</CODE> level linkable entities
|
|
|
1228 |
having that identification.
|
|
|
1229 |
<P>
|
|
|
1230 |
The elements of the list, <I>cap_linking</I>, also correspond one-to-one
|
|
|
1231 |
with the elements of the lists called <I>local_vars</I>
|
|
|
1232 |
in each of the <I>make_unit</I> constructions for the <CODE>UNIT</CODE>s
|
|
|
1233 |
in <I>groups</I>. The element of <I>local_vars</I> gives the number
|
|
|
1234 |
of <CODE>UNIT</CODE> level linkable entities having the identification
|
|
|
1235 |
in the corresponding member of <I>cap_linking</I>.
|
|
|
1236 |
<P>
|
|
|
1237 |
It is intended that new kinds of linkable entity can be added to the
|
|
|
1238 |
standard in a purely additive fashion, either to form a new standard
|
|
|
1239 |
or for private purposes.
|
|
|
1240 |
<P>
|
|
|
1241 |
<I>ext_linkage</I> provides a list of lists of <CODE>LINKEXTERN</CODE>s.
|
|
|
1242 |
These <CODE>LINKEXTERN</CODE>s specify the associations between the
|
|
|
1243 |
names to be used outside the <CODE>CAPSULE</CODE> and the linkable
|
|
|
1244 |
entities by which the <CODE>UNIT</CODE>s make objects available within
|
|
|
1245 |
the <CODE>CAPSULE</CODE>.
|
|
|
1246 |
<P>
|
|
|
1247 |
The list, <I>groups</I>, provides the non-linkage information of the
|
|
|
1248 |
<CODE>CAPSULE</CODE>.
|
|
|
1249 |
<P>
|
|
|
1250 |
|
|
|
1251 |
<HR>
|
|
|
1252 |
<H2>5.12. <A NAME=M54>CAPSULE_LINK</A></H2>
|
|
|
1253 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
1254 |
<B>Is coding extendable</B>: no<P>
|
|
|
1255 |
An auxiliary <CODE>SORT</CODE> which gives the number of linkable
|
|
|
1256 |
entities of a given kind at <CODE>CAPSULE</CODE> level. It is used
|
|
|
1257 |
only in <I>make_capsule</I>.
|
|
|
1258 |
<P>
|
|
|
1259 |
|
|
|
1260 |
<H3>5.12.1. <A NAME=M55>make_capsule_link</A></H3>
|
|
|
1261 |
<B>Encoding number</B>: 0<P>
|
|
|
1262 |
<PRE>
|
|
|
1263 |
<I>sn</I>: TDFIDENT
|
|
|
1264 |
<I>n</I>: TDFINT
|
|
|
1265 |
-> CAPSULE_LINK
|
|
|
1266 |
</PRE>
|
|
|
1267 |
<I>n</I> is the number of <CODE>CAPSULE</CODE> level linkable entities
|
|
|
1268 |
(numbered from 0 to <I>n</I>-1) of the kind given by <I>sn</I>. <I>sn</I>
|
|
|
1269 |
corresponds to the linkable entity identification.
|
|
|
1270 |
<P>
|
|
|
1271 |
|
|
|
1272 |
<HR>
|
|
|
1273 |
<H2>5.13. <A NAME=M56>CASELIM</A></H2>
|
|
|
1274 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
1275 |
<B>Is coding extendable</B>: no<P>
|
|
|
1276 |
An auxiliary <CODE>SORT</CODE> which provides lower and upper bounds
|
|
|
1277 |
and the <CODE>LABEL</CODE> destination for the <I>case</I> construction.
|
|
|
1278 |
<P>
|
|
|
1279 |
|
|
|
1280 |
<H3>5.13.1. <A NAME=M58>make_caselim</A></H3>
|
|
|
1281 |
<B>Encoding number</B>: 0<P>
|
|
|
1282 |
<PRE>
|
|
|
1283 |
<I>branch</I>: LABEL
|
|
|
1284 |
<I>lower</I>: SIGNED_NAT
|
|
|
1285 |
<I>upper</I>: SIGNED_NAT
|
|
|
1286 |
-> CASELIM
|
|
|
1287 |
</PRE>
|
|
|
1288 |
Makes a triple of destination and limits. The <I>case</I> construction
|
|
|
1289 |
uses a list of <CODE>CASELIM</CODE>s. If the control variable of the
|
|
|
1290 |
<I>case</I> lies between <I>lower</I>
|
|
|
1291 |
and <I>upper</I>, control passes to <I>branch</I>.
|
|
|
1292 |
<P>
|
|
|
1293 |
|
|
|
1294 |
<HR>
|
|
|
1295 |
<H2>5.14. <A NAME=M59>ERROR_CODE</A></H2>
|
|
|
1296 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
1297 |
<B>Is coding extendable</B>: yes<P>
|
|
|
1298 |
|
|
|
1299 |
<H3>5.14.1. <A NAME=M60>nil_access</A></H3>
|
|
|
1300 |
<B>Encoding number</B>: 1<P>
|
|
|
1301 |
<PRE>
|
|
|
1302 |
-> ERROR_CODE
|
|
|
1303 |
</PRE>
|
|
|
1304 |
Delivers the <CODE>ERROR_CODE</CODE> arising from an attempt to access
|
|
|
1305 |
a nil pointer in an operation with <CODE>TRANSFER_MODE</CODE>
|
|
|
1306 |
<I>trap_on_nil</I>.
|
|
|
1307 |
<P>
|
|
|
1308 |
|
|
|
1309 |
<H3>5.14.2. <A NAME=M61>overflow</A></H3>
|
|
|
1310 |
<B>Encoding number</B>: 2<P>
|
|
|
1311 |
<PRE>
|
|
|
1312 |
-> ERROR_CODE
|
|
|
1313 |
</PRE>
|
|
|
1314 |
Delivers the <CODE>ERROR_CODE</CODE> arising from a numerical exceptional
|
|
|
1315 |
result in an operation with <CODE>ERROR_TREATMENT</CODE>
|
|
|
1316 |
<I>trap</I>(<I>overflow</I>).
|
|
|
1317 |
<P>
|
|
|
1318 |
|
|
|
1319 |
<H3>5.14.3. <A NAME=M62>stack_overflow</A></H3>
|
|
|
1320 |
<B>Encoding number</B>: 3<P>
|
|
|
1321 |
<PRE>
|
|
|
1322 |
-> ERROR_CODE
|
|
|
1323 |
</PRE>
|
|
|
1324 |
Delivers the <CODE>ERROR_CODE</CODE> arising from a stack overflow
|
|
|
1325 |
in the call of a procedure defined with <CODE>PROCPROPS</CODE>
|
|
|
1326 |
<I>check_stack.</I><P>
|
|
|
1327 |
<P>
|
|
|
1328 |
|
|
|
1329 |
<HR>
|
|
|
1330 |
<H2>5.15. <A NAME=M301>ERROR_TREATMENT</A></H2>
|
|
|
1331 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
1332 |
<B>Is coding extendable</B>: yes<P>
|
|
|
1333 |
These values describe the way to handle various forms of error which
|
|
|
1334 |
can occur during the evaluation of operations.
|
|
|
1335 |
<P>
|
|
|
1336 |
<I>It is expected that additional <CODE>ERROR_TREATMENT</CODE>s will
|
|
|
1337 |
be needed.</I>
|
|
|
1338 |
<P>
|
|
|
1339 |
|
|
|
1340 |
<H3>5.15.1. <A NAME=M64>errt_apply_token</A></H3>
|
|
|
1341 |
<B>Encoding number</B>: 1<P>
|
|
|
1342 |
<PRE>
|
|
|
1343 |
<I>token_value</I>: TOKEN
|
|
|
1344 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
1345 |
-> ERROR_TREATMENT
|
|
|
1346 |
</PRE>
|
|
|
1347 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
1348 |
<I>token_args</I> to give an <CODE>ERROR_TREATMENT</CODE>.
|
|
|
1349 |
<P>
|
|
|
1350 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
1351 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
1352 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
1353 |
<P>
|
|
|
1354 |
|
|
|
1355 |
<H3>5.15.2. <A NAME=M65>errt_cond</A></H3>
|
|
|
1356 |
<B>Encoding number</B>: 2<P>
|
|
|
1357 |
<PRE>
|
|
|
1358 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
1359 |
<I>e1</I>: BITSTREAM ERROR_TREATMENT
|
|
|
1360 |
<I>e2</I>: BITSTREAM ERROR_TREATMENT
|
|
|
1361 |
-> ERROR_TREATMENT
|
|
|
1362 |
</PRE>
|
|
|
1363 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
1364 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
1365 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
1366 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
1367 |
and <I>e1</I> is ignored and never processed.
|
|
|
1368 |
<P>
|
|
|
1369 |
|
|
|
1370 |
<H3>5.15.3. <A NAME=M66>continue</A></H3>
|
|
|
1371 |
<B>Encoding number</B>: 3<P>
|
|
|
1372 |
<PRE>
|
|
|
1373 |
-> ERROR_TREATMENT
|
|
|
1374 |
</PRE>
|
|
|
1375 |
If an operation with a <I>continue</I> <CODE>ERROR_TREATMENT</CODE>
|
|
|
1376 |
causes an error, some value of the correct <CODE>SHAPE</CODE> shall
|
|
|
1377 |
be delivered. This value shall have the same properties as is specified
|
|
|
1378 |
in <I>make_value</I>.
|
|
|
1379 |
<P>
|
|
|
1380 |
|
|
|
1381 |
<H3>5.15.4. <A NAME=M68>error_jump</A></H3>
|
|
|
1382 |
<B>Encoding number</B>: 4<P>
|
|
|
1383 |
<PRE>
|
|
|
1384 |
<I>lab</I>: LABEL
|
|
|
1385 |
-> ERROR_TREATMENT
|
|
|
1386 |
</PRE>
|
|
|
1387 |
<I>error_jump</I> produces an <CODE>ERROR_TREATMENT</CODE> which requires
|
|
|
1388 |
that control be passed to <I>lab</I> if it is invoked. <I>lab</I>
|
|
|
1389 |
will be in scope.
|
|
|
1390 |
<P>
|
|
|
1391 |
If a construction has an <I>error_jump</I> <CODE>ERROR_TREATMENT</CODE>
|
|
|
1392 |
and the jump is taken, the canonical order specifies only that the
|
|
|
1393 |
jump occurs after evaluating the construction. It is not specified
|
|
|
1394 |
how many further constructions are evaluated.
|
|
|
1395 |
<P>
|
|
|
1396 |
<I>This rule implies that a further construction is needed to guarantee
|
|
|
1397 |
that errors have been processed. This is not yet included. The effect
|
|
|
1398 |
of nearby procedure calls or exits also needs definition.</I>
|
|
|
1399 |
<P>
|
|
|
1400 |
|
|
|
1401 |
<H3>5.15.5. <A NAME=M69>trap</A></H3>
|
|
|
1402 |
<B>Encoding number</B>: 5<P>
|
|
|
1403 |
<PRE>
|
|
|
1404 |
<I>trap_list</I>: LIST(ERROR_CODE)
|
|
|
1405 |
-> ERROR_TREATMENT
|
|
|
1406 |
</PRE>
|
|
|
1407 |
The list of <CODE>ERROR_CODES</CODE> in <I>trap_list</I> specifies
|
|
|
1408 |
a set of possible exceptional behaviours. If any of these occur in
|
|
|
1409 |
an construction with <CODE>ERROR_TREATMENT</CODE> <I>trap</I>, the
|
|
|
1410 |
TDF exception handling is invoked (see <A HREF="spec10.html#17">section
|
|
|
1411 |
7.8</A>).
|
|
|
1412 |
<P>
|
|
|
1413 |
The observations on canonical ordering in <I>error_jump</I> apply
|
|
|
1414 |
equally here.
|
|
|
1415 |
<P>
|
|
|
1416 |
|
|
|
1417 |
<H3>5.15.6. <A NAME=M70>wrap</A></H3>
|
|
|
1418 |
<B>Encoding number</B>: 6<P>
|
|
|
1419 |
<PRE>
|
|
|
1420 |
-> ERROR_TREATMENT
|
|
|
1421 |
</PRE>
|
|
|
1422 |
<I>wrap</I> is an <CODE>ERROR_TREATMENT</CODE> which will only be
|
|
|
1423 |
used in constructions with integer operands and delivering <CODE>EXP</CODE>
|
|
|
1424 |
<CODE>INTEGER</CODE>(<I>v</I>) where either the lower bound of <I>v</I>
|
|
|
1425 |
is zero or the construction is not one of <I>mult, power, div0, div1,
|
|
|
1426 |
div2, rem0, rem1, rem2</I>. The result will be evaluated and any bits
|
|
|
1427 |
in the result lying outside the representing <CODE>VARIETY</CODE>
|
|
|
1428 |
will be discarded (see <A HREF="spec10.html#51">Representing integers</A>).
|
|
|
1429 |
<P>
|
|
|
1430 |
|
|
|
1431 |
<H3>5.15.7. <A NAME=M71>impossible</A></H3>
|
|
|
1432 |
<B>Encoding number</B>: 7<P>
|
|
|
1433 |
<PRE>
|
|
|
1434 |
-> ERROR_TREATMENT
|
|
|
1435 |
</PRE>
|
|
|
1436 |
<I>impossible</I> is an <CODE>ERROR_TREATMENT</CODE> which means that
|
|
|
1437 |
this error will not occur in the construct concerned.
|
|
|
1438 |
<P>
|
|
|
1439 |
<I>impossible is possibly a misnomer. If an error occurs the result
|
|
|
1440 |
is undefined.</I>
|
|
|
1441 |
<P>
|
|
|
1442 |
|
|
|
1443 |
<HR>
|
|
|
1444 |
<H2>5.16. <A NAME=M302>EXP</A></H2>
|
|
|
1445 |
<B>Number of encoding bits</B>: 7<BR>
|
|
|
1446 |
<B>Is coding extendable</B>: yes<P>
|
|
|
1447 |
<CODE>EXP</CODE>s are pieces of TDF which are translated into program.
|
|
|
1448 |
<CODE>EXP</CODE> is by far the richest <CODE>SORT</CODE>. There are
|
|
|
1449 |
few primitive <CODE>EXP</CODE>s: most of the constructions take arguments
|
|
|
1450 |
which are a mixture of <CODE>EXP</CODE>s and other <CODE>SORT</CODE>s.
|
|
|
1451 |
There are constructs delivering <CODE>EXP</CODE>s that correspond
|
|
|
1452 |
to the declarations, program structure, procedure calls, assignments,
|
|
|
1453 |
pointer manipulation, arithmetic operations, tests etc. of programming
|
|
|
1454 |
languages.
|
|
|
1455 |
<P>
|
|
|
1456 |
|
|
|
1457 |
<H3>5.16.1. <A NAME=M73>exp_apply_token</A></H3>
|
|
|
1458 |
<B>Encoding number</B>: 1<P>
|
|
|
1459 |
<PRE>
|
|
|
1460 |
<I>token_value</I>: TOKEN
|
|
|
1461 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
1462 |
-> EXP <I>x</I>
|
|
|
1463 |
</PRE>
|
|
|
1464 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
1465 |
<I>token_args</I> to give an <CODE>EXP</CODE>.
|
|
|
1466 |
<P>
|
|
|
1467 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
1468 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
1469 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
1470 |
<P>
|
|
|
1471 |
|
|
|
1472 |
<H3>5.16.2. <A NAME=M75>exp_cond</A></H3>
|
|
|
1473 |
<B>Encoding number</B>: 2<P>
|
|
|
1474 |
<PRE>
|
|
|
1475 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
1476 |
<I>e1</I>: BITSTREAM EXP <I>x</I>
|
|
|
1477 |
<I>e2</I>: BITSTREAM EXP <I>y</I>
|
|
|
1478 |
-> EXP (<I>control</I> ? <I>x</I> : <I>y</I>)
|
|
|
1479 |
</PRE>
|
|
|
1480 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
1481 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
1482 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
1483 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
1484 |
and <I>e1</I> is ignored and never processed.
|
|
|
1485 |
<P>
|
|
|
1486 |
|
|
|
1487 |
<H3>5.16.3. <A NAME=M76>abs</A></H3>
|
|
|
1488 |
<B>Encoding number</B>: 3<P>
|
|
|
1489 |
<PRE>
|
|
|
1490 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
1491 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
1492 |
-> EXP INTEGER(<I>v</I>)
|
|
|
1493 |
</PRE>
|
|
|
1494 |
The absolute value of the result produced by <I>arg1</I> is delivered.
|
|
|
1495 |
<P>
|
|
|
1496 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
1497 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
1498 |
in the way specified by <I>ov_err</I>.
|
|
|
1499 |
<P>
|
|
|
1500 |
|
|
|
1501 |
<H3>5.16.4. <A NAME=M77>add_to_ptr</A></H3>
|
|
|
1502 |
<B>Encoding number</B>: 4<P>
|
|
|
1503 |
<PRE>
|
|
|
1504 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1505 |
<I>arg2</I>: EXP OFFSET(<I>y</I>, <I>z</I>)
|
|
|
1506 |
-> EXP POINTER(<I>z</I>)
|
|
|
1507 |
</PRE>
|
|
|
1508 |
<I>arg1</I> is evaluated, giving <I>p</I>, and <I>arg2</I> is evaluated
|
|
|
1509 |
and the results are added to produce the answer. The result is derived
|
|
|
1510 |
from the pointer delivered by <I>arg1</I>. The intention is to produce
|
|
|
1511 |
a <CODE>POINTER</CODE> displaced from the argument <CODE>POINTER</CODE>
|
|
|
1512 |
by the given amount.
|
|
|
1513 |
<P>
|
|
|
1514 |
<I>x</I> will include <I>y</I>.
|
|
|
1515 |
<P>
|
|
|
1516 |
<I>arg1</I> may deliver a null <CODE>POINTER</CODE>. In this case
|
|
|
1517 |
the result is derived from a null <CODE>POINTER</CODE> which counts
|
|
|
1518 |
as an original <CODE>POINTER</CODE>. Further <CODE>OFFSET</CODE>s
|
|
|
1519 |
may be added to the result, but the only other useful operation on
|
|
|
1520 |
the result of adding a number of <CODE>OFFSET</CODE>s to a null <CODE>POINTER
|
|
|
1521 |
</CODE>
|
|
|
1522 |
is to <I>subtract_ptrs</I> a null <CODE>POINTER</CODE> from it.
|
|
|
1523 |
<P>
|
|
|
1524 |
The result will be less than or equal (in the sense of <I>pointer_test</I>)
|
|
|
1525 |
to the result of applying <I>add_to_ptr</I> to the original pointer
|
|
|
1526 |
from which <I>p</I> is derived and the size of the space allocated
|
|
|
1527 |
for the original pointer.
|
|
|
1528 |
<P>
|
|
|
1529 |
<I>In the simple representation of <CODE>POINTER</CODE> arithmetic
|
|
|
1530 |
(see
|
|
|
1531 |
<A HREF="spec10.html#26">Memory Model</A>) add_to_ptr is represented
|
|
|
1532 |
by addition. The constraint "x includes y" ensures that
|
|
|
1533 |
no padding has to be inserted in this case.</I>
|
|
|
1534 |
<P>
|
|
|
1535 |
|
|
|
1536 |
<H3>5.16.5. <A NAME=M78>and</A></H3>
|
|
|
1537 |
<B>Encoding number</B>: 5<P>
|
|
|
1538 |
<PRE>
|
|
|
1539 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
1540 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
1541 |
-> EXP INTEGER(<I>v</I>)
|
|
|
1542 |
</PRE>
|
|
|
1543 |
The arguments are evaluated producing integer values of the same
|
|
|
1544 |
<CODE>VARIETY</CODE>, <I>v</I>. The result is the bitwise <I>and</I>
|
|
|
1545 |
of the two values in the representing <CODE>VARIETY</CODE>. The result
|
|
|
1546 |
is delivered with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
1547 |
<P>
|
|
|
1548 |
See <A HREF="spec10.html#51">Representing integers</A>.
|
|
|
1549 |
<P>
|
|
|
1550 |
|
|
|
1551 |
<H3>5.16.6. <A NAME=M80>apply_proc</A></H3>
|
|
|
1552 |
<B>Encoding number</B>: 6<P>
|
|
|
1553 |
<PRE>
|
|
|
1554 |
<I>result_shape</I>: SHAPE
|
|
|
1555 |
<I>p</I>: EXP PROC
|
|
|
1556 |
<I>params</I>: LIST(EXP)
|
|
|
1557 |
<I>var_param</I>: OPTION(EXP)
|
|
|
1558 |
-> EXP <I>result_shape</I>
|
|
|
1559 |
</PRE>
|
|
|
1560 |
<I>p, params</I> and <I>var_param</I> (if present) are evaluated in
|
|
|
1561 |
any interleaved order. The procedure, <I>p</I>, is applied to the
|
|
|
1562 |
parameters. The result of the procedure call, which will have
|
|
|
1563 |
<I>result_shape</I>, is delivered as the result of the construction.
|
|
|
1564 |
<P>
|
|
|
1565 |
The canonical order of evaluation is as if the definition were in-lined.
|
|
|
1566 |
That is, the actual parameters are evaluated interleaved in any order
|
|
|
1567 |
and used to initialise variables which are identified by the formal
|
|
|
1568 |
parameters during the evaluation of the procedure body. When this
|
|
|
1569 |
is complete the body is evaluated. So <I>apply_proc</I> is evaluated
|
|
|
1570 |
like a <I>variable</I> construction, and obeys similar rules for order
|
|
|
1571 |
of evaluation.
|
|
|
1572 |
<P>
|
|
|
1573 |
If <I>p</I> delivers a null procedure the effect is undefined.
|
|
|
1574 |
<P>
|
|
|
1575 |
<I>var_param</I> is intended to communicate parameters which vary
|
|
|
1576 |
in <CODE>SHAPE</CODE> from call to call. Access to these parameters
|
|
|
1577 |
during the procedure is performed by using <CODE>OFFSET</CODE> arithmetic.
|
|
|
1578 |
Note that it is necessary to place these values on <I>var_param_alignment</I>
|
|
|
1579 |
because of the definition of <I>make_proc</I>.
|
|
|
1580 |
<P>
|
|
|
1581 |
The optional <I>var_param</I> should not be confused with variable
|
|
|
1582 |
argument lists in the C (<I><stdarg.h></I> or <I><varargs.h></I>)
|
|
|
1583 |
sense, which are communicated by extending the <I>params</I> list.
|
|
|
1584 |
This is discussed further in <A HREF="spec10.html#18">section 7.9</A>.
|
|
|
1585 |
If the number of arguments in the <I>params</I> list differs from
|
|
|
1586 |
the number of elements in the <I>params_intro</I> of the corresponding
|
|
|
1587 |
<I>make_proc</I>, then <I>var_param</I> must not be present.
|
|
|
1588 |
<P>
|
|
|
1589 |
All calls to the same procedure will yield results of the same
|
|
|
1590 |
<CODE>SHAPE</CODE>.
|
|
|
1591 |
<P>
|
|
|
1592 |
For notes on the intended implementation of procedures see
|
|
|
1593 |
<A HREF="spec10.html#18">section 7.9</A>.
|
|
|
1594 |
<P>
|
|
|
1595 |
|
|
|
1596 |
<H3>5.16.7. <A NAME=M81>apply_general_proc</A></H3>
|
|
|
1597 |
<!-- BREAK 5 -->
|
|
|
1598 |
<B>Encoding number</B>: 7<P>
|
|
|
1599 |
<PRE>
|
|
|
1600 |
<I>result_shape</I>: SHAPE
|
|
|
1601 |
<I>prcprops</I>: OPTION(PROCPROPS)
|
|
|
1602 |
<I>p</I>: EXP PROC
|
|
|
1603 |
<I>callers_intro</I>: LIST(OTAGEXP)
|
|
|
1604 |
<I>callee_pars</I>: CALLEES
|
|
|
1605 |
<I>postlude</I>: EXP TOP
|
|
|
1606 |
-> EXP <I>result_shape</I>
|
|
|
1607 |
</PRE>
|
|
|
1608 |
<I>p</I>, <I>callers_intro</I> and <I>callee_pars</I> are evaluated
|
|
|
1609 |
in any order. The procedure, <I>p</I>, is applied to the parameters.
|
|
|
1610 |
The result of the procedure call, which will have <I>result_shape</I>,
|
|
|
1611 |
is delivered as the result of the construction.
|
|
|
1612 |
<P>
|
|
|
1613 |
If <I>p</I> delivers a null procedure the effect is undefined.
|
|
|
1614 |
<P>
|
|
|
1615 |
Any <CODE>TAG</CODE> introduced by an <CODE>OTAGEXP</CODE> in
|
|
|
1616 |
<I>callers_intro</I> is available in <I>postlude</I> which will be
|
|
|
1617 |
evaluated after the application.
|
|
|
1618 |
<P>
|
|
|
1619 |
<I>postlude</I> will not contain any <I>local_allocs</I> or calls
|
|
|
1620 |
of procedures with untidy returns. If <I>prcprops</I> include
|
|
|
1621 |
<I>untidy</I>, <I>postlude</I> will be <I>make_top</I>.
|
|
|
1622 |
<P>
|
|
|
1623 |
The canonical order of evaluation is as if the definition of <I>p</I>
|
|
|
1624 |
were inlined in a manner dependent on <I>prcprops</I>.
|
|
|
1625 |
<P>
|
|
|
1626 |
If none of the <CODE>PROCPROPS</CODE> <I>var_callers</I>, <I>var_callees</I>
|
|
|
1627 |
and <I>check_stack</I> are present the inlining is as follows, supposing
|
|
|
1628 |
that P is the body of the definition of <I>p</I>:<P>
|
|
|
1629 |
Let R<I>i</I> be the value of the <CODE>EXP</CODE> of the i<I>th</I>
|
|
|
1630 |
<CODE>OTAGEXP</CODE> in <I>callers_intro</I> and T<I>i</I> be its
|
|
|
1631 |
<CODE>TAG</CODE> (if it is present). Let E<I>i</I> be the i<I>th</I>
|
|
|
1632 |
value in <I>callee_pars</I>.<BR>
|
|
|
1633 |
Let r<I>i</I> be the i<I>th</I> formal caller parameter <CODE>TAG</CODE>
|
|
|
1634 |
of <I>p</I>.<BR>
|
|
|
1635 |
Let e<I>i</I> be the i<I>th</I> formal callee parameter <CODE>TAG</CODE>
|
|
|
1636 |
of <I>p</I>.
|
|
|
1637 |
<P>
|
|
|
1638 |
Each R<I>i</I> is used to initialise a variable which is identified
|
|
|
1639 |
by r<I>i</I>; there will be exactly as many R<I>i</I> as r<I>i</I>.The
|
|
|
1640 |
scope of these variable definitions is a sequence consisting of three
|
|
|
1641 |
components - the identification of a <CODE>TAG</CODE> <I>res</I> with
|
|
|
1642 |
the result of a binding of P, followed by a binding of <I>postlude</I>,
|
|
|
1643 |
followed by an <I>obtain_tag</I> of <I>res</I> giving the result of
|
|
|
1644 |
the inlined procedure call.
|
|
|
1645 |
<P>
|
|
|
1646 |
The binding of P consists of using each E<I>i</I> to initialise a
|
|
|
1647 |
variable identified with e<I>i</I>; there will be exactly as many
|
|
|
1648 |
E<I>i</I> as e<I>i</I>. The scope of these variable definitions is
|
|
|
1649 |
P modified so that the first <I>return</I> or <I>untidy_return</I>
|
|
|
1650 |
encountered in P gives the result of the binding. If it ends with
|
|
|
1651 |
a <I>return</I>, any space generated by <I>local_allocs</I> within
|
|
|
1652 |
the binding is freed (in the sense of <I>local_free</I>) at this point.
|
|
|
1653 |
If it ends with <I>untidy_return</I>, no freeing will take place.
|
|
|
1654 |
<P>
|
|
|
1655 |
The binding of <I>postlude</I> consists of identifying each T<I>i</I>
|
|
|
1656 |
(if present) with the contents of the variable identified by r<I>i</I>.
|
|
|
1657 |
The scope of these identifications is <I>postlude</I>.
|
|
|
1658 |
<P>
|
|
|
1659 |
If the <CODE>PROCPROPS</CODE> <I>var_callers</I> is present, the inlining
|
|
|
1660 |
process is modified by:<BR>
|
|
|
1661 |
A compound variable is constructed initialised to R<I>i</I> in order;
|
|
|
1662 |
the alignment and padding of each individual R<I>i</I> will be given
|
|
|
1663 |
by an exact application of <I>parameter_alignment</I> on the
|
|
|
1664 |
<CODE>SHAPE</CODE> of R<I>i</I>. Each r<I>i</I> is then identified
|
|
|
1665 |
with a pointer to the copy of R<I>i</I> within the compound variable;
|
|
|
1666 |
there will be at least as many R<I>i</I> as r<I>i</I>. The evaluation
|
|
|
1667 |
then continues as above with the scope of these identifications being
|
|
|
1668 |
the sequence.
|
|
|
1669 |
<P>
|
|
|
1670 |
If the <CODE>PROCPROPS</CODE> <I>var_callees</I> is present, the inlining
|
|
|
1671 |
process is modified by:<BR>
|
|
|
1672 |
The binding of P is done by generating (as if by <I>local_alloc</I>)
|
|
|
1673 |
a pointer to space for a compound value constructed from each E<I>i</I>
|
|
|
1674 |
in order (just as for <I>var_callers</I>). Each e<I>i</I> is identified
|
|
|
1675 |
with a pointer to the copy of E<I>i</I> within the generated space;
|
|
|
1676 |
there will be at least as many e<I>i</I> as E<I>i</I>. P is evaluated
|
|
|
1677 |
within the scope of these identifications as before. Note that the
|
|
|
1678 |
generation of space for these callee parameters is a <I>local_alloc</I>
|
|
|
1679 |
with the binding of P, and hence will not be freed if P ends with
|
|
|
1680 |
an
|
|
|
1681 |
<I>untidy_return</I>.
|
|
|
1682 |
<P>
|
|
|
1683 |
|
|
|
1684 |
<H3>5.16.8. <A NAME=M82>assign</A></H3>
|
|
|
1685 |
<B>Encoding number</B>: 8<P>
|
|
|
1686 |
<PRE>
|
|
|
1687 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1688 |
<I>arg2</I>: EXP <I>y</I>
|
|
|
1689 |
-> EXP TOP
|
|
|
1690 |
</PRE>
|
|
|
1691 |
The value produced by <I>arg2</I> will be put in the space indicated
|
|
|
1692 |
by <I>arg1</I>.
|
|
|
1693 |
<P>
|
|
|
1694 |
<I>x</I> will include <I>alignment</I>(<I>y</I>).
|
|
|
1695 |
<P>
|
|
|
1696 |
<I>y</I> will not be a <CODE>BITFIELD</CODE>.
|
|
|
1697 |
<P>
|
|
|
1698 |
If the space which the pointer indicates does not lie wholly within
|
|
|
1699 |
the space indicated by the original pointer from which it is derived,
|
|
|
1700 |
the effect is undefined.
|
|
|
1701 |
<P>
|
|
|
1702 |
If the value delivered by <I>arg1</I> is a null pointer the effect
|
|
|
1703 |
is undefined.
|
|
|
1704 |
<P>
|
|
|
1705 |
See <A HREF="spec10.html#48">Overlapping</A> and
|
|
|
1706 |
<A HREF="spec10.html#50">Incomplete assignment</A>.
|
|
|
1707 |
<P>
|
|
|
1708 |
<I>The constraint "x will include alignment(y)" ensures
|
|
|
1709 |
in the simple memory model that no change is needed to the <CODE>POINTER</CODE>.
|
|
|
1710 |
</I>
|
|
|
1711 |
<P>
|
|
|
1712 |
|
|
|
1713 |
<H3>5.16.9. <A NAME=M83>assign_with_mode</A></H3>
|
|
|
1714 |
<B>Encoding number</B>: 9<P>
|
|
|
1715 |
<PRE>
|
|
|
1716 |
<I>md</I>: TRANSFER_MODE
|
|
|
1717 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1718 |
<I>arg2</I>: EXP <I>y</I>
|
|
|
1719 |
-> EXP TOP
|
|
|
1720 |
</PRE>
|
|
|
1721 |
The value produced by <I>arg2</I> will be put in the space indicated
|
|
|
1722 |
by <I>arg1</I>. The assignment will be carried out as specified by
|
|
|
1723 |
the <CODE>TRANSFER_MODE</CODE> (q.v.).
|
|
|
1724 |
<P>
|
|
|
1725 |
If <I>md</I> consists of <I>standard_transfer_mode</I> only, then
|
|
|
1726 |
<I>assign_with_mode</I> is the same as <I>assign</I>.
|
|
|
1727 |
<P>
|
|
|
1728 |
<I>x</I> will include <I>alignment</I>(<I>y</I>).
|
|
|
1729 |
<P>
|
|
|
1730 |
<I>y</I> will not be a <CODE>BITFIELD</CODE>.
|
|
|
1731 |
<P>
|
|
|
1732 |
If the space which the pointer indicates does not lie wholly within
|
|
|
1733 |
the space indicated by the original pointer from which it is derived,
|
|
|
1734 |
the effect is undefined.
|
|
|
1735 |
<P>
|
|
|
1736 |
If the value delivered by <I>arg1</I> is a null pointer the effect
|
|
|
1737 |
is undefined.
|
|
|
1738 |
<P>
|
|
|
1739 |
See <A HREF="spec10.html#48">Overlapping</A> and
|
|
|
1740 |
<A HREF="spec10.html#50">Incomplete assignment</A>.
|
|
|
1741 |
<P>
|
|
|
1742 |
|
|
|
1743 |
<H3>5.16.10. <A NAME=M84>bitfield_assign</A></H3>
|
|
|
1744 |
<B>Encoding number</B>: 10<P>
|
|
|
1745 |
<PRE>
|
|
|
1746 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1747 |
<I>arg2</I>: EXP OFFSET(<I>y</I>, <I>z</I>)
|
|
|
1748 |
<I>arg3</I>: EXP BITFIELD(<I>v</I>)
|
|
|
1749 |
-> EXP TOP
|
|
|
1750 |
</PRE>
|
|
|
1751 |
The value delivered by <I>arg3</I> is assigned at a displacement given
|
|
|
1752 |
by <I>arg2</I> from the pointer delivered by <I>arg1</I>.
|
|
|
1753 |
<P>
|
|
|
1754 |
<I>x</I> will include <I>y</I> and <I>z</I> will include <I>v</I>.
|
|
|
1755 |
<P>
|
|
|
1756 |
<I>arg2</I>, <CODE>BITFIELD</CODE>(<I>v</I>) will be
|
|
|
1757 |
<I>variety-enclosed</I> (see <A HREF="spec10.html#66">section 7.24</A>).
|
|
|
1758 |
<P>
|
|
|
1759 |
|
|
|
1760 |
<H3>5.16.11. <A NAME=M85>bitfield_assign_with_mode</A></H3>
|
|
|
1761 |
<B>Encoding number</B>: 11<P>
|
|
|
1762 |
<PRE>
|
|
|
1763 |
<I>md</I>: TRANSFER_MODE
|
|
|
1764 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1765 |
<I>arg2</I>: EXP OFFSET(<I>y</I>, <I>z</I>)
|
|
|
1766 |
<I>arg3</I>: EXP BITFIELD(<I>v</I>)
|
|
|
1767 |
-> EXP TOP
|
|
|
1768 |
</PRE>
|
|
|
1769 |
The value delivered by <I>arg3</I> is assigned at a displacement given
|
|
|
1770 |
by <I>arg2</I> from the pointer delivered by <I>arg1</I>.The assignment
|
|
|
1771 |
will be carried out as specified by the <CODE>TRANSFER_MODE</CODE>
|
|
|
1772 |
(q.v.).
|
|
|
1773 |
<P>
|
|
|
1774 |
If <I>md</I> consists of <I>standard_transfer_mode</I> only, then
|
|
|
1775 |
<I>bitfield_assign_with_mode</I> is the same as <I>bitfield_assign</I>.
|
|
|
1776 |
<P>
|
|
|
1777 |
<I>x</I> will include <I>y</I> and <I>z</I> will include <I>v</I>.
|
|
|
1778 |
<P>
|
|
|
1779 |
<I>arg2</I>, <CODE>BITFIELD</CODE>(<I>v</I>) will be
|
|
|
1780 |
<I>variety-enclosed</I>.(see <A HREF="spec10.html#66">section 7.24</A>).
|
|
|
1781 |
<P>
|
|
|
1782 |
|
|
|
1783 |
<H3>5.16.12. <A NAME=M86>bitfield_contents</A></H3>
|
|
|
1784 |
<B>Encoding number</B>: 12<P>
|
|
|
1785 |
<PRE>
|
|
|
1786 |
<I>v</I>: BITFIELD_VARIETY
|
|
|
1787 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1788 |
<I>arg2</I>: EXP OFFSET(<I>y</I>, <I>z</I>)
|
|
|
1789 |
-> EXP BITFIELD(<I>v</I>)
|
|
|
1790 |
</PRE>
|
|
|
1791 |
The bitfield of <CODE>BITFIELD_VARIETY</CODE> <I>v</I>, located at
|
|
|
1792 |
the displacement delivered by <I>arg2</I> from the pointer delivered
|
|
|
1793 |
by <I>arg1</I> is extracted and delivered.
|
|
|
1794 |
<P>
|
|
|
1795 |
<I>x</I> will include <I>y</I> and <I>z</I> will include <I>v</I>.
|
|
|
1796 |
<P>
|
|
|
1797 |
<I>arg2</I>, <CODE>BITFIELD</CODE>(<I>v</I>) will be <I>variety_enclosed</I>
|
|
|
1798 |
(see <A HREF="spec10.html#66">section 7.24</A>).
|
|
|
1799 |
<P>
|
|
|
1800 |
|
|
|
1801 |
<H3>5.16.13. <A NAME=M87>bitfield_contents_with_mode</A></H3>
|
|
|
1802 |
<B>Encoding number</B>: 13<P>
|
|
|
1803 |
<PRE>
|
|
|
1804 |
<I>md</I>: TRANSFER_MODE
|
|
|
1805 |
<I>v</I>: BITFIELD_VARIETY
|
|
|
1806 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1807 |
<I>arg2</I>: EXP OFFSET(<I>y</I>, <I>z</I>)
|
|
|
1808 |
-> EXP BITFIELD(<I>v</I>)
|
|
|
1809 |
</PRE>
|
|
|
1810 |
The bitfield of <CODE>BITFIELD_VARIETY </CODE><I>v</I>, located at
|
|
|
1811 |
the displacement delivered by <I>arg2</I> from the pointer delivered
|
|
|
1812 |
by <I>arg1</I> is extracted and delivered.The operation will be carried
|
|
|
1813 |
out as specified by the <CODE>TRANSFER_MODE</CODE> (q.v.).
|
|
|
1814 |
<P>
|
|
|
1815 |
If <I>md</I> consists of <I>standard_transfer_mode</I> only, then
|
|
|
1816 |
<I>bitfield_contents_with_mode</I> is the same as <I>bitfield_contents</I>.
|
|
|
1817 |
<P>
|
|
|
1818 |
<I>x</I> will include <I>y</I> and <I>z</I> will include <I>v</I>.
|
|
|
1819 |
<P>
|
|
|
1820 |
<I>arg2</I>, <CODE>BITFIELD</CODE>(<I>v</I>) will be <I>variety_enclosed</I>
|
|
|
1821 |
(see <A HREF="spec10.html#66">section 7.24</A>).
|
|
|
1822 |
<P>
|
|
|
1823 |
|
|
|
1824 |
<H3>5.16.14. <A NAME=M89>case</A></H3>
|
|
|
1825 |
<B>Encoding number</B>: 14<P>
|
|
|
1826 |
<PRE>
|
|
|
1827 |
<I>exhaustive</I>: BOOL
|
|
|
1828 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
1829 |
<I>branches</I>: LIST(CASELIM)
|
|
|
1830 |
-> EXP (<I>exhaustive</I> ? BOTTOM : TOP)
|
|
|
1831 |
</PRE>
|
|
|
1832 |
<I>control</I> is evaluated to produce an integer value, <I>c</I>.
|
|
|
1833 |
Then <I>c</I> is tested to see if it lies inclusively between <I>lower</I>
|
|
|
1834 |
and <I>upper</I>, for each element of <I>branches</I>. If this tests
|
|
|
1835 |
succeeds, control passes to the label <I>branch</I> belonging to that
|
|
|
1836 |
<CODE>CASELIM</CODE> (see <A HREF="#M56">section 5.13</A>). If <I>c</I>
|
|
|
1837 |
lies between no pair, the construct delivers a value of
|
|
|
1838 |
<CODE>SHAPE TOP</CODE>. The order in which the comparisons are made
|
|
|
1839 |
is undefined.
|
|
|
1840 |
<P>
|
|
|
1841 |
The sets of <CODE>SIGNED_NAT</CODE>s in <I>branches</I> will be disjoint.
|
|
|
1842 |
<P>
|
|
|
1843 |
If <I>exhaustive</I> is true the value delivered by <I>control</I>
|
|
|
1844 |
will lie between one of the <I>lower</I>/<I>upper</I> pairs.
|
|
|
1845 |
<P>
|
|
|
1846 |
|
|
|
1847 |
<H3>5.16.15. <A NAME=M90>change_bitfield_to_int</A></H3>
|
|
|
1848 |
<B>Encoding number</B>: 15<P>
|
|
|
1849 |
<PRE>
|
|
|
1850 |
<I>v</I>: VARIETY
|
|
|
1851 |
<I>arg1</I>: EXP BITFIELD(<I>bv</I>)
|
|
|
1852 |
-> EXP INTEGER(<I>v</I>)
|
|
|
1853 |
</PRE>
|
|
|
1854 |
<I>arg1</I> is evaluated and converted to a <CODE>INTEGER</CODE>(<I>v</I>).
|
|
|
1855 |
<P>
|
|
|
1856 |
If <I>arg1</I> exceed the bounds of <I>v</I>, the effect is undefined.
|
|
|
1857 |
<P>
|
|
|
1858 |
|
|
|
1859 |
<H3>5.16.16. <A NAME=M91>change_floating_variety</A></H3>
|
|
|
1860 |
<B>Encoding number</B>: 16<P>
|
|
|
1861 |
<PRE>
|
|
|
1862 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
1863 |
<I>r</I>: FLOATING_VARIETY
|
|
|
1864 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
1865 |
-> EXP FLOATING(<I>r</I>)
|
|
|
1866 |
</PRE>
|
|
|
1867 |
<I>arg1</I> is evaluated and will produce floating point value, <I>fp</I>.
|
|
|
1868 |
The value <I>fp</I> is delivered, changed to the representation of
|
|
|
1869 |
the <CODE>FLOATING_VARIETY</CODE> <I>r</I>.
|
|
|
1870 |
<P>
|
|
|
1871 |
Either <I>r</I> and <I>f</I> will both real or both complex.
|
|
|
1872 |
<P>
|
|
|
1873 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
1874 |
<P>
|
|
|
1875 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
1876 |
<P>
|
|
|
1877 |
|
|
|
1878 |
<H3>5.16.17. <A NAME=M92>change_variety</A></H3>
|
|
|
1879 |
<B>Encoding number</B>: 17<P>
|
|
|
1880 |
<PRE>
|
|
|
1881 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
1882 |
<I>r</I>: VARIETY
|
|
|
1883 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
1884 |
-> EXP INTEGER(<I>r</I>)
|
|
|
1885 |
</PRE>
|
|
|
1886 |
<I>arg1</I> is evaluated and will produce an integer value, <I>a</I>.
|
|
|
1887 |
The value <I>a</I> is delivered, changed to the representation of
|
|
|
1888 |
the <CODE>VARIETY</CODE> <I>r</I>.
|
|
|
1889 |
<P>
|
|
|
1890 |
If <I>a</I> is not contained in the <CODE>VARIETY</CODE> being used
|
|
|
1891 |
to represent <I>r</I>, an overflow occurs and is handled according
|
|
|
1892 |
to <I>ov_err</I>.
|
|
|
1893 |
<P>
|
|
|
1894 |
|
|
|
1895 |
<H3>5.16.18. <A NAME=M93>change_int_to_bitfield</A></H3>
|
|
|
1896 |
<B>Encoding number</B>: 18<P>
|
|
|
1897 |
<PRE>
|
|
|
1898 |
<I>bv</I>: BITFIELD_VARIETY
|
|
|
1899 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
1900 |
-> EXP BITFIELD(<I>bv</I>)
|
|
|
1901 |
</PRE>
|
|
|
1902 |
<I>arg1</I> is evaluated and converted to a <CODE>BITFIELD</CODE>(<I>bv</I>).
|
|
|
1903 |
<P>
|
|
|
1904 |
If <I>arg1</I> exceed the bounds of <I>bv</I>, the effect is undefined.
|
|
|
1905 |
<P>
|
|
|
1906 |
|
|
|
1907 |
<H3>5.16.19. <A NAME=M94>complex_conjugate</A></H3>
|
|
|
1908 |
<B>Encoding number</B>: 19<P>
|
|
|
1909 |
<PRE>
|
|
|
1910 |
<I>c</I>: EXP FLOATING(<I>cv</I>)
|
|
|
1911 |
-> EXP FLOATING(<I>cv</I>)
|
|
|
1912 |
</PRE>
|
|
|
1913 |
Delivers the complex conjugate of <I>c</I>.
|
|
|
1914 |
<P>
|
|
|
1915 |
<I>cv</I> will be a complex floating variety.
|
|
|
1916 |
<P>
|
|
|
1917 |
|
|
|
1918 |
<H3>5.16.20. <A NAME=M95>component</A></H3>
|
|
|
1919 |
<B>Encoding number</B>: 20<P>
|
|
|
1920 |
<PRE>
|
|
|
1921 |
<I>sha</I>: SHAPE
|
|
|
1922 |
<I>arg1</I>: EXP COMPOUND(EXP OFFSET(<I>x</I>, <I>y</I>))
|
|
|
1923 |
<I>arg2</I>: EXP OFFSET(<I>x</I>, <I>alignment</I>(<I>sha</I>))
|
|
|
1924 |
-> EXP <I>sha</I>
|
|
|
1925 |
</PRE>
|
|
|
1926 |
<I>arg1</I> is evaluated to produce a <CODE>COMPOUND</CODE> value.
|
|
|
1927 |
The component of this value at the <CODE>OFFSET</CODE> given by <I>arg2</I>
|
|
|
1928 |
is delivered. This will have <CODE>SHAPE</CODE> <I>sha</I>.
|
|
|
1929 |
<P>
|
|
|
1930 |
<I>arg2</I> will be a constant and non-negative (see
|
|
|
1931 |
<A HREF="spec10.html#7">Constant evaluation</A>).
|
|
|
1932 |
<P>
|
|
|
1933 |
If <I>sha</I> is a <CODE>BITFIELD</CODE> then <I>arg2</I>, <I>sha</I>
|
|
|
1934 |
will be <I>variety_enclosed</I> (see <A HREF="spec10.html#66">section
|
|
|
1935 |
7.24</A>).
|
|
|
1936 |
<P>
|
|
|
1937 |
|
|
|
1938 |
<H3>5.16.21. <A NAME=M96>concat_nof</A></H3>
|
|
|
1939 |
<B>Encoding number</B>: 21<P>
|
|
|
1940 |
<PRE>
|
|
|
1941 |
<I>arg1</I>: EXP NOF(<I>n</I>, <I>s</I>)
|
|
|
1942 |
<I>arg2</I>: EXP NOF(<I>m</I>, <I>s</I>)
|
|
|
1943 |
-> EXP NOF(<I>n</I>+<I>m</I>, <I>s</I>)
|
|
|
1944 |
</PRE>
|
|
|
1945 |
<I>arg1</I> and <I>arg2</I> are evaluated and their results concatenated.
|
|
|
1946 |
In the result the components derived from <I>arg1</I> will have lower
|
|
|
1947 |
indices than those derived from <I>arg2</I>.
|
|
|
1948 |
<P>
|
|
|
1949 |
|
|
|
1950 |
<H3>5.16.22. <A NAME=M97>conditional</A></H3>
|
|
|
1951 |
<B>Encoding number</B>: 22<P>
|
|
|
1952 |
<PRE>
|
|
|
1953 |
<I>altlab_intro</I>: LABEL
|
|
|
1954 |
<I>first</I>: EXP <I>x</I>
|
|
|
1955 |
<I>alt</I>: EXP <I>z</I>
|
|
|
1956 |
-> EXP (<I>x</I> LUB <I>z</I>)
|
|
|
1957 |
</PRE>
|
|
|
1958 |
<!-- BREAK 1 -->
|
|
|
1959 |
<I>first</I> is evaluated. If <I>first</I> produces a result, <I>f</I>,
|
|
|
1960 |
this value is delivered as the result of the whole construct, and
|
|
|
1961 |
<I>alt</I> is not evaluated.
|
|
|
1962 |
<P>
|
|
|
1963 |
If <I>goto</I>(<I>altlab_intro</I>) or any other jump (including
|
|
|
1964 |
<I>long_jump</I>) to <I>altlab_intro</I> is obeyed during the evaluation
|
|
|
1965 |
of <I>first</I>, then the evaluation of <I>first</I> will stop, <I>alt</I>
|
|
|
1966 |
will be evaluated and its result delivered as the result of the construction.
|
|
|
1967 |
<P>
|
|
|
1968 |
The lifetime of <I>altlab_intro</I> is the evaluation of <I>first</I>.
|
|
|
1969 |
<I>altlab_intro</I> will not be used within <I>alt</I>.
|
|
|
1970 |
<P>
|
|
|
1971 |
The actual order of evaluation of the constituents shall be indistinguishable
|
|
|
1972 |
in all observable effects (apart from time) from evaluating all the
|
|
|
1973 |
obeyed parts of <I>first</I> before any obeyed part of <I>alt</I>.
|
|
|
1974 |
Note that this specifically includes any defined error handling.
|
|
|
1975 |
<P>
|
|
|
1976 |
For LUB see <A HREF="spec10.html#70">Least Upper Bound</A>.
|
|
|
1977 |
<P>
|
|
|
1978 |
|
|
|
1979 |
<H3>5.16.23. <A NAME=M98>contents</A></H3>
|
|
|
1980 |
<B>Encoding number</B>: 23<P>
|
|
|
1981 |
<PRE>
|
|
|
1982 |
<I>s</I>: SHAPE
|
|
|
1983 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
1984 |
-> EXP <I>s</I>
|
|
|
1985 |
</PRE>
|
|
|
1986 |
A value of <CODE>SHAPE</CODE> <I>s</I> will be extracted from the
|
|
|
1987 |
start of the space indicated by the pointer, and this is delivered.
|
|
|
1988 |
<P>
|
|
|
1989 |
<I>x</I> will include <I>alignment</I>(<I>s</I>).
|
|
|
1990 |
<P>
|
|
|
1991 |
<I>s</I> will not be a <CODE>BITFIELD</CODE>.
|
|
|
1992 |
<P>
|
|
|
1993 |
<P>
|
|
|
1994 |
If the space which the pointer indicates does not lie wholly within
|
|
|
1995 |
the space indicated by the original pointer from which it is derived,
|
|
|
1996 |
the effect is undefined.
|
|
|
1997 |
<P>
|
|
|
1998 |
If the value delivered by <I>arg1</I> is a null pointer the effect
|
|
|
1999 |
is undefined.
|
|
|
2000 |
<P>
|
|
|
2001 |
<I>The constraint "x will include alignment(s)" ensures
|
|
|
2002 |
in the simple memory model that no change is needed to the <CODE>POINTER</CODE>.
|
|
|
2003 |
</I>
|
|
|
2004 |
<P>
|
|
|
2005 |
|
|
|
2006 |
<H3>5.16.24. <A NAME=M99>contents_with_mode</A></H3>
|
|
|
2007 |
<B>Encoding number</B>: 24<P>
|
|
|
2008 |
<PRE>
|
|
|
2009 |
<I>md</I>: TRANSFER_MODE
|
|
|
2010 |
<I>s</I>: SHAPE
|
|
|
2011 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
2012 |
-> EXP <I>s</I>
|
|
|
2013 |
</PRE>
|
|
|
2014 |
A value of <CODE>SHAPE</CODE> <I>s</I> will be extracted from the
|
|
|
2015 |
start of the space indicated by the pointer, and this is delivered.
|
|
|
2016 |
The operation will be carried out as specified by the
|
|
|
2017 |
<CODE>TRANSFER_MODE</CODE> (q.v.).
|
|
|
2018 |
<P>
|
|
|
2019 |
If <I>md</I> consists of <I>standard_transfer_mode</I> only, then
|
|
|
2020 |
<I>contents_with_mode</I> is the same as <I>contents</I>.
|
|
|
2021 |
<P>
|
|
|
2022 |
<I>x</I> will include <I>alignment</I>(<I>s</I>).
|
|
|
2023 |
<P>
|
|
|
2024 |
<I>s</I> will not be a <CODE>BITFIELD</CODE>.
|
|
|
2025 |
<P>
|
|
|
2026 |
If the space which the pointer indicates does not lie wholly within
|
|
|
2027 |
the space indicated by the original pointer from which it is derived,
|
|
|
2028 |
the effect is undefined.
|
|
|
2029 |
<P>
|
|
|
2030 |
If the value delivered by <I>arg1</I> is a null pointer the effect
|
|
|
2031 |
is undefined.
|
|
|
2032 |
<P>
|
|
|
2033 |
|
|
|
2034 |
<H3>5.16.25. <A NAME=M101>current_env</A></H3>
|
|
|
2035 |
<B>Encoding number</B>: 25<P>
|
|
|
2036 |
<PRE>
|
|
|
2037 |
-> EXP POINTER(<I>fa</I>)
|
|
|
2038 |
</PRE>
|
|
|
2039 |
A value of <CODE>SHAPE POINTER</CODE>(<I>fa</I>) is created and delivered.
|
|
|
2040 |
It gives access to the variables, identities and parameters in the
|
|
|
2041 |
current procedure activation which are declared as having
|
|
|
2042 |
<CODE>ACCESS</CODE> <I>visible</I>.
|
|
|
2043 |
<P>
|
|
|
2044 |
If the immediately enclosing procedure is defined by
|
|
|
2045 |
<I>make_general_proc</I>, then <I>fa</I> is the set union of
|
|
|
2046 |
<I>local_alignment</I> and the alignments of the kinds of parameters
|
|
|
2047 |
defined. That is to say, if there are caller parameters, then the
|
|
|
2048 |
alignment includes <I>callers_alignment</I>(<I>x</I>) where <I>x</I>
|
|
|
2049 |
is true if and only if the <CODE>PROCPROPS</CODE> <I>var_callers</I>
|
|
|
2050 |
is present; if there are callee parameters, the alignment includes
|
|
|
2051 |
<I>callees_alignment</I>(<I>x</I>) where <I>x</I> is true if and only
|
|
|
2052 |
if the
|
|
|
2053 |
<CODE>PROCPROPS</CODE> <I>var_callees</I> is present.
|
|
|
2054 |
<P>
|
|
|
2055 |
If the immediately enclosing procedure is defined by <I>make_proc</I>,
|
|
|
2056 |
then <I>fa</I> = { <I>locals_alignment</I>,
|
|
|
2057 |
<I>callers_alignment</I>(<I>false</I>) }.
|
|
|
2058 |
<P>
|
|
|
2059 |
If an <CODE>OFFSET</CODE> produced by <I>env_offset</I> is added to
|
|
|
2060 |
a
|
|
|
2061 |
<CODE>POINTER</CODE> produced by <I>current_env</I> from an activation
|
|
|
2062 |
of the procedure which contains the declaration of the <CODE>TAG</CODE>
|
|
|
2063 |
used by <I>env_offset</I>, then the result is an original
|
|
|
2064 |
<CODE>POINTER</CODE>, notwithstanding the normal rules for
|
|
|
2065 |
<I>add_to_ptr</I> (see <A HREF="spec10.html#44">Original pointers</A>).
|
|
|
2066 |
<P>
|
|
|
2067 |
If an <CODE>OFFSET</CODE> produced by <I>env_offset</I> is added to
|
|
|
2068 |
such a pointer from an inappropriate procedure the effect is undefined.
|
|
|
2069 |
<P>
|
|
|
2070 |
|
|
|
2071 |
<H3>5.16.26. <A NAME=M102>div0</A></H3>
|
|
|
2072 |
<B>Encoding number</B>: 26<P>
|
|
|
2073 |
<PRE>
|
|
|
2074 |
<I>div_by_0_err</I>: ERROR_TREATMENT
|
|
|
2075 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
2076 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
2077 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
2078 |
-> EXP INTEGER(<I>v</I>)
|
|
|
2079 |
</PRE>
|
|
|
2080 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
2081 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>,
|
|
|
2082 |
<I>v</I>. Either the value <I>a</I> D1 <I>b</I> or the value <I>a</I>
|
|
|
2083 |
D2 <I>b</I> is delivered as the result of the construct, with the
|
|
|
2084 |
same
|
|
|
2085 |
<CODE>SHAPE</CODE> as the arguments. Different occurrences of
|
|
|
2086 |
<I>div0</I> in the same capsule can use D1 or D2 independently.
|
|
|
2087 |
<P>
|
|
|
2088 |
If <I>b</I> is zero a div_by_zero error occurs and is handled by
|
|
|
2089 |
<I>div_by_0_err</I>.
|
|
|
2090 |
<P>
|
|
|
2091 |
If <I>b</I> is not zero and the result cannot be expressed in the
|
|
|
2092 |
<CODE>VARIETY</CODE> being used to represent <I>v</I> an overflow
|
|
|
2093 |
occurs and is handled by <I>ov_err</I>.
|
|
|
2094 |
<P>
|
|
|
2095 |
Producers may assume that shifting and <I>div0</I> by a constant which
|
|
|
2096 |
is a power of two yield equally good code.
|
|
|
2097 |
<P>
|
|
|
2098 |
See <A HREF="spec10.html#10">Division and modulus</A> for the definitions
|
|
|
2099 |
of D1, D2, M1 and M2.
|
|
|
2100 |
<P>
|
|
|
2101 |
|
|
|
2102 |
<H3>5.16.27. <A NAME=M103>div1</A></H3>
|
|
|
2103 |
<B>Encoding number</B>: 27<P>
|
|
|
2104 |
<PRE>
|
|
|
2105 |
<I>div_by_0_err</I>: ERROR_TREATMENT
|
|
|
2106 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
2107 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
2108 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
2109 |
-> EXP INTEGER(<I>v</I>)
|
|
|
2110 |
</PRE>
|
|
|
2111 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
2112 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
2113 |
The value <I>a</I> D1 <I>b</I> is delivered as the result of the construct,
|
|
|
2114 |
with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
2115 |
<P>
|
|
|
2116 |
If <I>b</I> is zero a div_by_zero error occurs and is handled by
|
|
|
2117 |
<I>div_by_0_err</I>.
|
|
|
2118 |
<P>
|
|
|
2119 |
If <I>b</I> is not zero and the result cannot be expressed in the
|
|
|
2120 |
<CODE>VARIETY</CODE> being used to represent <I>v</I> an overflow
|
|
|
2121 |
occurs and is handled by <I>ov_err</I>.
|
|
|
2122 |
<P>
|
|
|
2123 |
Producers may assume that shifting and <I>div1</I> by a constant which
|
|
|
2124 |
is a power of two yield equally good code.
|
|
|
2125 |
<P>
|
|
|
2126 |
See <A HREF="spec10.html#10">Division and modulus</A> for the definitions
|
|
|
2127 |
of D1, D2, M1 and M2.
|
|
|
2128 |
<P>
|
|
|
2129 |
|
|
|
2130 |
<H3>5.16.28. <A NAME=M104>div2</A></H3>
|
|
|
2131 |
<B>Encoding number</B>: 28<P>
|
|
|
2132 |
<PRE>
|
|
|
2133 |
<I>div_by_0_err</I>: ERROR_TREATMENT
|
|
|
2134 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
2135 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
2136 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
2137 |
-> EXP INTEGER(<I>v</I>)
|
|
|
2138 |
</PRE>
|
|
|
2139 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
2140 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
2141 |
The value <I>a</I> D2 <I>b</I> is delivered as the result of the construct,
|
|
|
2142 |
with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
2143 |
<P>
|
|
|
2144 |
If <I>b</I> is zero a div_by_zero error occurs and is handled by
|
|
|
2145 |
<I>div_by_0_err</I>.
|
|
|
2146 |
<P>
|
|
|
2147 |
If <I>b</I> is not zero and the result cannot be expressed in the
|
|
|
2148 |
<CODE>VARIETY</CODE> being used to represent <I>v</I> an overflow
|
|
|
2149 |
occurs and is handled by <I>ov_err</I>.
|
|
|
2150 |
<P>
|
|
|
2151 |
Producers may assume that shifting and <I>div2</I> by a constant which
|
|
|
2152 |
is a power of two yield equally good code if the lower bound of <I>v</I>
|
|
|
2153 |
is zero.
|
|
|
2154 |
<P>
|
|
|
2155 |
See <A HREF="spec10.html#10">Division and modulus</A> for the definitions
|
|
|
2156 |
of D1, D2, M1 and M2.
|
|
|
2157 |
<P>
|
|
|
2158 |
|
|
|
2159 |
<H3>5.16.29. <A NAME=M105>env_offset</A></H3>
|
|
|
2160 |
<B>Encoding number</B>: 29<P>
|
|
|
2161 |
<PRE>
|
|
|
2162 |
<I>fa</I>: ALIGNMENT
|
|
|
2163 |
<I>y</I>: ALIGNMENT
|
|
|
2164 |
<I>t</I>: TAG <I>x</I>
|
|
|
2165 |
-> EXP OFFSET(<I>fa</I>, <I>y</I>)
|
|
|
2166 |
</PRE>
|
|
|
2167 |
<I>t</I> will be the tag of a <I>variable</I>, <I>identify</I> or
|
|
|
2168 |
procedure parameter with the <I>visible</I> property within a procedure
|
|
|
2169 |
defined by <I>make_general_proc</I> or <I>make_proc</I>.
|
|
|
2170 |
<P>
|
|
|
2171 |
If it is defined in a make_general_proc, let P be its associated
|
|
|
2172 |
<CODE>PROCPROPS</CODE>; otherwise let P be the <CODE>PROCPROPS</CODE>
|
|
|
2173 |
{<I>locals_alignment</I>, <I>caller_alignment</I>(<I>false</I>)}.
|
|
|
2174 |
<P>
|
|
|
2175 |
If <I>t</I> is the <CODE>TAG</CODE> of a <I>variable</I> or <I>identify,
|
|
|
2176 |
fa</I>
|
|
|
2177 |
will contain <I>locals_alignment</I>; if it is a caller parameter
|
|
|
2178 |
<I>fa</I> will contain a <I>caller_alignment</I>(<I>b</I>) where <I>b
|
|
|
2179 |
</I>is true if and only if P contains <I>var_callers</I> ; if it is
|
|
|
2180 |
a callee parameter <I>fa</I> will contain a <I>callee_alignment</I>(<I>b</I>)
|
|
|
2181 |
where <I>b</I> is true if and only if P contains <I>var_callees</I>.
|
|
|
2182 |
<P>
|
|
|
2183 |
If t is the <CODE>TAG</CODE> of a <I>variable</I> or parameter, the
|
|
|
2184 |
result is the <CODE>OFFSET</CODE> of its position, within any procedure
|
|
|
2185 |
environment which derives from the procedure containing the declaration
|
|
|
2186 |
of the variable or parameter, relative to its environment pointer.
|
|
|
2187 |
In this case
|
|
|
2188 |
<I>x</I> will be <CODE>POINTER</CODE>(<I>y).</I><P> If t is the <CODE>TAG</CODE>
|
|
|
2189 |
of an <I>identify</I>, the result will be an <CODE>OFFSET</CODE> of
|
|
|
2190 |
space which holds the value. This pointer will not be used to alter
|
|
|
2191 |
the value. In this case <I>y</I> will be <I>alignment</I>(<I>x</I>).
|
|
|
2192 |
<P>
|
|
|
2193 |
See <A HREF="spec10.html#19">section 7.10</A>.
|
|
|
2194 |
<P>
|
|
|
2195 |
|
|
|
2196 |
<H3>5.16.30. <A NAME=M106>env_size</A></H3>
|
|
|
2197 |
<B>Encoding number</B>: 30<P>
|
|
|
2198 |
<PRE>
|
|
|
2199 |
<I>proctag</I>: TAG PROC
|
|
|
2200 |
-> EXP OFFSET(<I>locals_alignment</I>, {})
|
|
|
2201 |
</PRE>
|
|
|
2202 |
Delivers an <CODE>OFFSET</CODE> of a space sufficient to contain all
|
|
|
2203 |
the variables and identifications, explicit or implicit in the procedure
|
|
|
2204 |
identified by <I>proctag</I>. This will not include the space required
|
|
|
2205 |
for any <I>local_allocs</I> or procedure calls within the procedure.
|
|
|
2206 |
<P>
|
|
|
2207 |
<I>proctag</I> will be defined in the current <CODE>CAPSULE</CODE>
|
|
|
2208 |
by a
|
|
|
2209 |
<CODE>TAGDEF</CODE> identification of a <I>make_proc</I> or a
|
|
|
2210 |
<I>make_general_proc</I>.
|
|
|
2211 |
<P>
|
|
|
2212 |
|
|
|
2213 |
<H3>5.16.31. <A NAME=M107>fail_installer</A></H3>
|
|
|
2214 |
<B>Encoding number</B>: 31<P>
|
|
|
2215 |
<PRE>
|
|
|
2216 |
<I>message</I>: STRING<I>(k, n)</I>
|
|
|
2217 |
-> EXP BOTTOM
|
|
|
2218 |
</PRE>
|
|
|
2219 |
Any attempt to use this operation to produce code will result in a
|
|
|
2220 |
failure of the installation process. <I>message</I> will give information
|
|
|
2221 |
about the reason for this failure which should be passed to the installation
|
|
|
2222 |
manager.
|
|
|
2223 |
<P>
|
|
|
2224 |
|
|
|
2225 |
<H3>5.16.32. <A NAME=M108>float_int</A></H3>
|
|
|
2226 |
<B>Encoding number</B>: 32<P>
|
|
|
2227 |
<PRE>
|
|
|
2228 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2229 |
<I>f</I>: FLOATING_VARIETY
|
|
|
2230 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
2231 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2232 |
</PRE>
|
|
|
2233 |
<I>arg1</I> is evaluated to produce an integer value, which is converted
|
|
|
2234 |
to the representation of <I>f</I> and delivered.
|
|
|
2235 |
<P>
|
|
|
2236 |
If <I>f</I> is complex the real part of the result will be derived
|
|
|
2237 |
from <I>arg1</I> and the imaginary part will be zero.
|
|
|
2238 |
<P>
|
|
|
2239 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2240 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2241 |
<P>
|
|
|
2242 |
|
|
|
2243 |
<H3>5.16.33. <A NAME=M109>floating_abs</A></H3>
|
|
|
2244 |
<B>Encoding number</B>: 33<P>
|
|
|
2245 |
<PRE>
|
|
|
2246 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2247 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2248 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2249 |
</PRE>
|
|
|
2250 |
<I>arg1</I> is evaluated and will produce a floating point value,
|
|
|
2251 |
<I>a</I>, of the <CODE>FLOATING_VARIETY</CODE>, <I>f</I>. The absolute
|
|
|
2252 |
value of <I>a</I> is delivered as the result of the construct, with
|
|
|
2253 |
the same <CODE>SHAPE</CODE> as the argument.
|
|
|
2254 |
<P>
|
|
|
2255 |
Though <I>floating_abs</I> cannot produce an overflow it can give
|
|
|
2256 |
an invalid operand exception which is handled by <I>flpt_err</I>.
|
|
|
2257 |
<P>
|
|
|
2258 |
<I>f</I> will not be complex.
|
|
|
2259 |
<P>
|
|
|
2260 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2261 |
<P>
|
|
|
2262 |
|
|
|
2263 |
<H3>5.16.34. <A NAME=M110>floating_div</A></H3>
|
|
|
2264 |
<B>Encoding number</B>: 34<P>
|
|
|
2265 |
<PRE>
|
|
|
2266 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2267 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2268 |
<I>arg2</I>: EXP FLOATING(<I>f</I>)
|
|
|
2269 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2270 |
</PRE>
|
|
|
2271 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce floating
|
|
|
2272 |
point values, <I>a</I> and <I>b</I>, of the same
|
|
|
2273 |
<CODE>FLOATING_VARIETY</CODE>, <I>f</I>. The value <I>a</I>/<I>b</I>
|
|
|
2274 |
is delivered as the result of the construct, with the same
|
|
|
2275 |
<CODE>SHAPE</CODE> as the arguments.
|
|
|
2276 |
<P>
|
|
|
2277 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2278 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2279 |
<P>
|
|
|
2280 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2281 |
<P>
|
|
|
2282 |
|
|
|
2283 |
<H3>5.16.35. <A NAME=M111>floating_minus</A></H3>
|
|
|
2284 |
<B>Encoding number</B>: 35<P>
|
|
|
2285 |
<PRE>
|
|
|
2286 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2287 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2288 |
<I>arg2</I>: EXP FLOATING(<I>f</I>)
|
|
|
2289 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2290 |
</PRE>
|
|
|
2291 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce floating
|
|
|
2292 |
point values, <I>a</I> and <I>b</I>, of the same
|
|
|
2293 |
<CODE>FLOATING_VARIETY</CODE>, <I>f</I>. The value <I>a</I>-<I>b</I>
|
|
|
2294 |
is delivered as the result of the construct, with the same
|
|
|
2295 |
<CODE>SHAPE</CODE> as the arguments.
|
|
|
2296 |
<P>
|
|
|
2297 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2298 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2299 |
<P>
|
|
|
2300 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2301 |
<P>
|
|
|
2302 |
|
|
|
2303 |
<H3>5.16.36. <A NAME=M112>floating_maximum</A></H3>
|
|
|
2304 |
<B>Encoding number</B>: 36<P>
|
|
|
2305 |
<PRE>
|
|
|
2306 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2307 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2308 |
<I>arg2</I>: EXP FLOATING(<I>f</I>)
|
|
|
2309 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2310 |
</PRE>
|
|
|
2311 |
The maximum of the values delivered by <I>arg1</I> and <I>arg2</I>
|
|
|
2312 |
is the result. <I>f</I> will not be complex.
|
|
|
2313 |
<P>
|
|
|
2314 |
If <I>arg1</I> and <I>arg2</I> are incomparable, <I>flpt_err</I> will
|
|
|
2315 |
be invoked.
|
|
|
2316 |
<P>
|
|
|
2317 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2318 |
<P>
|
|
|
2319 |
|
|
|
2320 |
<H3>5.16.37. <A NAME=M113>floating_minimum</A></H3>
|
|
|
2321 |
<B>Encoding number</B>: 37<P>
|
|
|
2322 |
<PRE>
|
|
|
2323 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2324 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2325 |
<I>arg2</I>: EXP FLOATING(<I>f</I>)
|
|
|
2326 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2327 |
</PRE>
|
|
|
2328 |
The minimum of the values delivered by <I>arg1</I> and <I>arg2</I>
|
|
|
2329 |
is the result. <I>f</I> will not be complex.
|
|
|
2330 |
<P>
|
|
|
2331 |
If <I>arg1</I> and <I>arg2</I> are incomparable, <I>flpt_err</I> will
|
|
|
2332 |
be invoked.
|
|
|
2333 |
<P>
|
|
|
2334 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2335 |
<P>
|
|
|
2336 |
|
|
|
2337 |
<H3>5.16.38. <A NAME=M114>floating_mult</A></H3>
|
|
|
2338 |
<B>Encoding number</B>: 38<P>
|
|
|
2339 |
<PRE>
|
|
|
2340 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2341 |
<I>arg1</I>: LIST(EXP)
|
|
|
2342 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2343 |
</PRE>
|
|
|
2344 |
The arguments, <I>arg1</I>, are evaluated producing floating point
|
|
|
2345 |
values all of the same <CODE>FLOATING_VARIETY</CODE>, <I>f</I>. These
|
|
|
2346 |
values are multiplied in any order and the result of this multiplication
|
|
|
2347 |
is delivered as the result of the construct, with the same
|
|
|
2348 |
<CODE>SHAPE</CODE> as the arguments.
|
|
|
2349 |
<P>
|
|
|
2350 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2351 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2352 |
<P>
|
|
|
2353 |
<I>Note that separate floating_mult operations cannot in general be
|
|
|
2354 |
combined, because rounding errors need to be controlled. The reason
|
|
|
2355 |
for allowing floating_mult to take a variable number of arguments
|
|
|
2356 |
is to make it possible to specify that a number of multiplications
|
|
|
2357 |
can be re-ordered.</I>
|
|
|
2358 |
<P>
|
|
|
2359 |
If <I>arg1</I> contains one element the result is the value of that
|
|
|
2360 |
element. There will be at least one element in <I>arg1</I>.
|
|
|
2361 |
<P>
|
|
|
2362 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2363 |
<P>
|
|
|
2364 |
|
|
|
2365 |
<H3>5.16.39. <A NAME=M116>floating_negate</A></H3>
|
|
|
2366 |
<B>Encoding number</B>: 39<P>
|
|
|
2367 |
<PRE>
|
|
|
2368 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2369 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2370 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2371 |
</PRE>
|
|
|
2372 |
<I>arg1</I> is evaluated and will produce a floating point value,
|
|
|
2373 |
<I>a</I>, of the <CODE>FLOATING_VARIETY</CODE>, <I>f</I>. The value
|
|
|
2374 |
-<I>a</I> is delivered as the result of the construct, with the same
|
|
|
2375 |
<CODE>SHAPE</CODE> as the argument.
|
|
|
2376 |
<P>
|
|
|
2377 |
Though <I>floating_negate</I> cannot produce an overflow it can give
|
|
|
2378 |
an invalid operand exception which is handled by <I>flpt_err</I>.
|
|
|
2379 |
<P>
|
|
|
2380 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2381 |
<P>
|
|
|
2382 |
|
|
|
2383 |
<H3>5.16.40. <A NAME=M117>floating_plus</A></H3>
|
|
|
2384 |
<B>Encoding number</B>: 40<P>
|
|
|
2385 |
<PRE>
|
|
|
2386 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2387 |
<I>arg1</I>: LIST(EXP)
|
|
|
2388 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2389 |
</PRE>
|
|
|
2390 |
The arguments, <I>arg1</I>, are evaluated producing floating point
|
|
|
2391 |
values, all of the same <CODE>FLOATING_VARIETY</CODE>, <I>f</I>. These
|
|
|
2392 |
values are added in any order and the result of this addition is delivered
|
|
|
2393 |
as the result of the construct, with the same <CODE>SHAPE</CODE> as
|
|
|
2394 |
the arguments.
|
|
|
2395 |
<P>
|
|
|
2396 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2397 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2398 |
<P>
|
|
|
2399 |
<I>Note that separate floating_plus operations cannot in general be
|
|
|
2400 |
combined, because rounding errors need to be controlled. The reason
|
|
|
2401 |
for allowing floating_plus to take a variable number of arguments
|
|
|
2402 |
is to make it possible to specify that a number of multiplications
|
|
|
2403 |
can be re-ordered.</I>
|
|
|
2404 |
<P>
|
|
|
2405 |
If <I>arg1</I> contains one element the result is the value of that
|
|
|
2406 |
element. There will be at least one element in <I>arg1</I>.
|
|
|
2407 |
<P>
|
|
|
2408 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2409 |
<P>
|
|
|
2410 |
|
|
|
2411 |
<H3>5.16.41. <A NAME=M118>floating_power</A></H3>
|
|
|
2412 |
<B>Encoding number</B>: 41<P>
|
|
|
2413 |
<PRE>
|
|
|
2414 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2415 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2416 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
2417 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2418 |
</PRE>
|
|
|
2419 |
The result of <I>arg1</I> is raised to the power given by <I>arg2</I>.
|
|
|
2420 |
<P>
|
|
|
2421 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2422 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2423 |
<P>
|
|
|
2424 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2425 |
<P>
|
|
|
2426 |
|
|
|
2427 |
<H3>5.16.42. <A NAME=M119>floating_test</A></H3>
|
|
|
2428 |
<B>Encoding number</B>: 42<P>
|
|
|
2429 |
<PRE>
|
|
|
2430 |
<I>prob</I>: OPTION(NAT)
|
|
|
2431 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
2432 |
<I>nt</I>: NTEST
|
|
|
2433 |
<I>dest</I>: LABEL
|
|
|
2434 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2435 |
<I>arg2</I>: EXP FLOATING(<I>f</I>)
|
|
|
2436 |
-> EXP TOP
|
|
|
2437 |
</PRE>
|
|
|
2438 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce floating
|
|
|
2439 |
point values, <I>a</I> and <I>b</I>, of the same
|
|
|
2440 |
<CODE>FLOATING_VARIETY</CODE>, <I>f</I>. These values are compared
|
|
|
2441 |
using
|
|
|
2442 |
<I>nt</I>.
|
|
|
2443 |
<P>
|
|
|
2444 |
If <I>f</I> is complex then <I>nt</I> will be <I>equal</I> or
|
|
|
2445 |
<I>not_equal</I>.
|
|
|
2446 |
<P>
|
|
|
2447 |
If <I>a nt b</I>, this construction yields <CODE>TOP</CODE>. Otherwise
|
|
|
2448 |
control passes to <I>dest</I>.
|
|
|
2449 |
<P>
|
|
|
2450 |
If <I>prob</I> is present<I>, prob</I>/100 gives the probability that
|
|
|
2451 |
control will continue to the next construct (ie. not pass to <I>dest</I>).
|
|
|
2452 |
If <I>prob</I> is absent this probability is unknown.
|
|
|
2453 |
<P>
|
|
|
2454 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
2455 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
2456 |
<P>
|
|
|
2457 |
See also <A HREF="spec10.html#64">Floating point accuracy</A>.
|
|
|
2458 |
<P>
|
|
|
2459 |
|
|
|
2460 |
<H3>5.16.43. <A NAME=M120>goto</A></H3>
|
|
|
2461 |
<B>Encoding number</B>: 43<P>
|
|
|
2462 |
<PRE>
|
|
|
2463 |
<I>dest</I>: LABEL
|
|
|
2464 |
-> EXP BOTTOM
|
|
|
2465 |
</PRE>
|
|
|
2466 |
Control passes to the <CODE>EXP</CODE> labelled <I>dest</I>. This
|
|
|
2467 |
construct will only be used where <I>dest</I> is in scope.
|
|
|
2468 |
<P>
|
|
|
2469 |
|
|
|
2470 |
<H3>5.16.44. <A NAME=M121>goto_local_lv</A></H3>
|
|
|
2471 |
<B>Encoding number</B>: 44<P>
|
|
|
2472 |
<PRE>
|
|
|
2473 |
<I>arg1</I>: EXP POINTER(<I>{code</I>})
|
|
|
2474 |
-> EXP BOTTOM
|
|
|
2475 |
</PRE>
|
|
|
2476 |
<I>arg1</I> is evaluated. The label from which the value delivered
|
|
|
2477 |
by
|
|
|
2478 |
<I>arg1</I> was created will be within its lifetime and this construction
|
|
|
2479 |
will be obeyed in the same activation of the same procedure as the
|
|
|
2480 |
creation of the <CODE>POINTER(</CODE><I>{code</I><CODE>})</CODE>
|
|
|
2481 |
by <I>make_local_lv</I>. Control passes to this activation of this
|
|
|
2482 |
<CODE>LABEL</CODE>.
|
|
|
2483 |
<P>
|
|
|
2484 |
If <I>arg1</I> delivers a null <CODE>POINTER</CODE> the effect is
|
|
|
2485 |
undefined.
|
|
|
2486 |
<P>
|
|
|
2487 |
|
|
|
2488 |
<H3>5.16.45. <A NAME=M122>identify</A></H3>
|
|
|
2489 |
<!-- BREAK 3 -->
|
|
|
2490 |
<B>Encoding number</B>: 45<P>
|
|
|
2491 |
<PRE>
|
|
|
2492 |
<I>opt_access</I>: OPTION(ACCESS)
|
|
|
2493 |
<I>name_intro</I>: TAG <I>x</I>
|
|
|
2494 |
<I>definition</I>: EXP <I>x</I>
|
|
|
2495 |
<I>body</I>: EXP <I>y</I>
|
|
|
2496 |
-> EXP <I>y</I>
|
|
|
2497 |
</PRE>
|
|
|
2498 |
<I>definition</I> is evaluated to produce a value, <I>v</I>. Then
|
|
|
2499 |
<I>body</I> is evaluated. During this evaluation, <I>v</I> is bound
|
|
|
2500 |
to <I>name_intro</I>. This means that inside <I>body</I> an evaluation
|
|
|
2501 |
of <I>obtain_tag</I>(<I>name_intro</I>) will produce the value, <I>v</I>.
|
|
|
2502 |
<P>
|
|
|
2503 |
The value delivered by <I>identify</I> is that produced by <I>body</I>.
|
|
|
2504 |
<P>
|
|
|
2505 |
The <CODE>TAG</CODE> given for <I>name_intro</I> will not be reused
|
|
|
2506 |
within the current <CODE>UNIT</CODE>. No rules for the hiding of one
|
|
|
2507 |
<CODE>TAG</CODE> by another are given: this will not happen. The lifetime
|
|
|
2508 |
of <I>name_intro</I> is the evaluation of <I>body</I>.
|
|
|
2509 |
<P>
|
|
|
2510 |
If <I>opt_access</I> contains <I>visible</I>, it means that the value
|
|
|
2511 |
must not be aliased while the procedure containing this declaration
|
|
|
2512 |
is not the current procedure. Hence if there are any copies of this
|
|
|
2513 |
value they will need to be refreshed when the procedure is returned
|
|
|
2514 |
to. The easiest implementation when <I>opt_access</I> is <I>visible</I>
|
|
|
2515 |
may be to keep the value in memory, but this is not a necessary requirement.
|
|
|
2516 |
<P>
|
|
|
2517 |
The order in which the constituents of <I>definition</I> and <I>body</I>
|
|
|
2518 |
are evaluated shall be indistinguishable in all observable effects
|
|
|
2519 |
(apart from time) from completely evaluating <I>definition</I> before
|
|
|
2520 |
starting <I>body</I>. See the note about order in
|
|
|
2521 |
<A HREF="#M193">sequence</A>.
|
|
|
2522 |
<P>
|
|
|
2523 |
|
|
|
2524 |
<H3>5.16.46. <A NAME=M123>ignorable</A></H3>
|
|
|
2525 |
<B>Encoding number</B>: 46<P>
|
|
|
2526 |
<PRE>
|
|
|
2527 |
<I>arg1</I>: EXP <I>x</I>
|
|
|
2528 |
-> EXP <I>x</I>
|
|
|
2529 |
</PRE>
|
|
|
2530 |
If the result of this construction is discarded, <I>arg1</I> need
|
|
|
2531 |
not be evaluated, though evaluation is permitted. If the result is
|
|
|
2532 |
used it is the result of <I>arg1</I>.
|
|
|
2533 |
<P>
|
|
|
2534 |
|
|
|
2535 |
<H3>5.16.47. <A NAME=M124>imaginary_part</A></H3>
|
|
|
2536 |
<B>Encoding number</B>: 47<P>
|
|
|
2537 |
<PRE>
|
|
|
2538 |
<I>arg1</I>: EXP <I>c</I>
|
|
|
2539 |
-> EXP FLOATING (<I>float_of_complex(c)</I>)
|
|
|
2540 |
</PRE>
|
|
|
2541 |
<I>c</I> will be complex. Delivers the imaginary part of the value
|
|
|
2542 |
produced by <I>arg1</I>.
|
|
|
2543 |
<P>
|
|
|
2544 |
|
|
|
2545 |
<H3>5.16.48. <A NAME=M125>initial_value</A></H3>
|
|
|
2546 |
<B>Encoding number</B>: 48<P>
|
|
|
2547 |
<PRE>
|
|
|
2548 |
<I>init</I>: EXP <I>s</I>
|
|
|
2549 |
-> EXP <I>s</I>
|
|
|
2550 |
</PRE>
|
|
|
2551 |
<!-- BREAK 0 -->
|
|
|
2552 |
Any tag used as an argument of an <I>obtain_tag</I> in <I>init</I>
|
|
|
2553 |
will be global or defined within <I>init</I>.
|
|
|
2554 |
<P>
|
|
|
2555 |
All labels used in <I>init</I> will be defined within <I>init</I>.
|
|
|
2556 |
<P>
|
|
|
2557 |
<I>init</I> will be evaluated once only before any procedure application,
|
|
|
2558 |
other than those involved in this or other
|
|
|
2559 |
<I>initial_value</I> constructions, but after all load-time constant
|
|
|
2560 |
initialisations of TAGDEFs. The result of this evaluation is the value
|
|
|
2561 |
of the construction.
|
|
|
2562 |
<P>
|
|
|
2563 |
The order of evaluation of the different <I>initial_values</I> in
|
|
|
2564 |
a program is undefined.
|
|
|
2565 |
<P>
|
|
|
2566 |
See <A HREF="spec10.html#73">section 7.29</A>.
|
|
|
2567 |
<P>
|
|
|
2568 |
<P>
|
|
|
2569 |
|
|
|
2570 |
<H3>5.16.49. <A NAME=M127>integer_test</A></H3>
|
|
|
2571 |
<B>Encoding number</B>: 49<P>
|
|
|
2572 |
<PRE>
|
|
|
2573 |
<I>prob</I>: OPTION(NAT)
|
|
|
2574 |
<I>nt</I>: NTEST
|
|
|
2575 |
<I>dest</I>: LABEL
|
|
|
2576 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
2577 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
2578 |
-> EXP TOP
|
|
|
2579 |
</PRE>
|
|
|
2580 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
2581 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
2582 |
These values are compared using <I>nt</I>.
|
|
|
2583 |
<P>
|
|
|
2584 |
If <I>a nt b</I>, this construction yields <CODE>TOP</CODE>. Otherwise
|
|
|
2585 |
control passes to <I>dest</I>.
|
|
|
2586 |
<P>
|
|
|
2587 |
If <I>prob</I> is present, <I>prob</I>/100 gives the probability that
|
|
|
2588 |
control will continue to the next construct (ie. not pass to <I>dest</I>).
|
|
|
2589 |
If <I>prob</I> is absent this probability is unknown.
|
|
|
2590 |
<P>
|
|
|
2591 |
|
|
|
2592 |
<H3>5.16.50. <A NAME=M128>labelled</A></H3>
|
|
|
2593 |
<!-- BREAK 1 -->
|
|
|
2594 |
<B>Encoding number</B>: 50<P>
|
|
|
2595 |
<PRE>
|
|
|
2596 |
<I>labs_intro</I>: LIST(LABEL)
|
|
|
2597 |
<I>starter</I>: EXP <I>x</I>
|
|
|
2598 |
<I>places</I>: LIST(EXP)
|
|
|
2599 |
-> EXP <I>w</I>
|
|
|
2600 |
</PRE>
|
|
|
2601 |
The lists <I>labs_intro</I> and <I>places</I> shall have the same
|
|
|
2602 |
number of elements.
|
|
|
2603 |
<P>
|
|
|
2604 |
To evaluate the construction <I>starter</I> is evaluated. If its evaluation
|
|
|
2605 |
runs to completion producing a value, then this is delivered as the
|
|
|
2606 |
result of the whole construction. If a <I>goto</I> one of the
|
|
|
2607 |
<CODE>LABEL</CODE>s in <I>labs_intro</I> or any other jump to one
|
|
|
2608 |
of these <CODE>LABEL</CODE>s is evaluated, then the evaluation of
|
|
|
2609 |
<I>starter</I> stops and the corresponding element of <I>places</I>
|
|
|
2610 |
is evaluated. In the canonical ordering all the operations which
|
|
|
2611 |
are evaluated from <I>starter</I> are completed before any from an
|
|
|
2612 |
element of <I>places</I> is started. If the evaluation of the member
|
|
|
2613 |
of
|
|
|
2614 |
<I>places</I> produces a result this is the result of the construction.
|
|
|
2615 |
<P>
|
|
|
2616 |
If a jump to any of the <I>labs_intro</I> is obeyed then evaluation
|
|
|
2617 |
continues similarly. Such jumping may continue indefinitely, but if
|
|
|
2618 |
any <I>places</I> terminates, then the value it produces is the value
|
|
|
2619 |
delivered by the construction.
|
|
|
2620 |
<P>
|
|
|
2621 |
The <CODE>SHAPE</CODE> <I>w</I> is the LUB of <I>x</I> and all the
|
|
|
2622 |
<I>places</I>. See <A HREF="spec10.html#70">Least Upper Bound</A>.
|
|
|
2623 |
<P>
|
|
|
2624 |
The actual order of evaluation of the constituents shall be indistinguishable
|
|
|
2625 |
in all observable effects (apart from time) from that described above.
|
|
|
2626 |
Note that this specifically includes any defined error handling.
|
|
|
2627 |
<P>
|
|
|
2628 |
The lifetime of each of the <CODE>LABEL</CODE>s in <I>labs_intro</I>,
|
|
|
2629 |
is the evaluation of <I>starter</I> and all the elements of <I>places</I>.
|
|
|
2630 |
<P>
|
|
|
2631 |
|
|
|
2632 |
<H3>5.16.51. <A NAME=M129>last_local</A></H3>
|
|
|
2633 |
<B>Encoding number</B>: 51<P>
|
|
|
2634 |
<PRE>
|
|
|
2635 |
<I>x</I>: EXP OFFSET(<I>y</I>, <I>z</I>)
|
|
|
2636 |
-> EXP POINTER(<I>alloca_alignment</I>)
|
|
|
2637 |
</PRE>
|
|
|
2638 |
If the last use of <I>local_alloc</I> in the current activation of
|
|
|
2639 |
the current procedure was after the last use of <I>local_free</I>
|
|
|
2640 |
or
|
|
|
2641 |
<I>local_free_all</I>, then the value returned is the last
|
|
|
2642 |
<CODE>POINTER</CODE> allocated with <I>local_alloc</I>.
|
|
|
2643 |
<P>
|
|
|
2644 |
If the last use of <I>local_free</I> in the current activation of
|
|
|
2645 |
the current procedure was after the last use of <I>local_alloc</I>,
|
|
|
2646 |
then the result is the <CODE>POINTER</CODE> last allocated which is
|
|
|
2647 |
still active.
|
|
|
2648 |
<P>
|
|
|
2649 |
The result <CODE>POINTER</CODE> will have been created by
|
|
|
2650 |
<I>local_alloc</I> with the value of its <I>arg1</I> equal to the
|
|
|
2651 |
value of <I>x</I>.
|
|
|
2652 |
<P>
|
|
|
2653 |
If the last use of <I>local_free_all</I> in the current activation
|
|
|
2654 |
of the current procedure was after the last use of <I>local_alloc</I>,
|
|
|
2655 |
or if there has been no use of <I>local_alloc</I> in the current activation
|
|
|
2656 |
of the current procedure, then the result is undefined.
|
|
|
2657 |
<P>
|
|
|
2658 |
The <CODE>ALIGNMENT</CODE>, <I>alloca_alignment</I>, includes the
|
|
|
2659 |
set union of all the <CODE>ALIGNMENT</CODE>s which can be produced
|
|
|
2660 |
by
|
|
|
2661 |
<I>alignment</I> from any <CODE>SHAPE</CODE>. See
|
|
|
2662 |
<A HREF="spec10.html#34">Special alignments</A>.
|
|
|
2663 |
<P>
|
|
|
2664 |
|
|
|
2665 |
<H3>5.16.52. <A NAME=M130>local_alloc</A></H3>
|
|
|
2666 |
<B>Encoding number</B>: 52<P>
|
|
|
2667 |
<PRE>
|
|
|
2668 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
2669 |
-> EXP POINTER(<I>alloca_alignment</I>)
|
|
|
2670 |
</PRE>
|
|
|
2671 |
The <I>arg1</I> expression is evaluated and space is allocated sufficient
|
|
|
2672 |
to hold a value of the given size. <A NAME=M339>The result is an original
|
|
|
2673 |
pointer to this space</A>.
|
|
|
2674 |
<P>
|
|
|
2675 |
<I>x</I> will not consist entirely of bitfield alignments.
|
|
|
2676 |
<P>
|
|
|
2677 |
The initial contents of the space are not specified.
|
|
|
2678 |
<P>
|
|
|
2679 |
This allocation is as if on the stack of the current procedure, and
|
|
|
2680 |
the lifetime of the pointer ends when the current activation of the
|
|
|
2681 |
current procedure ends with a <I>return</I>, <I>return_to_label</I>
|
|
|
2682 |
or <I>tail_call</I> or if there is a long jump out of the activation.
|
|
|
2683 |
Any use of the pointer thereafter is undefined. Note the specific
|
|
|
2684 |
exclusion of the procedure ending with <I>untidy_return</I>; in this
|
|
|
2685 |
case the calling procedure becomes the current activation.
|
|
|
2686 |
<P>
|
|
|
2687 |
The uses of <I>local_alloc</I> within the procedure are ordered dynamically
|
|
|
2688 |
as they occur, and this order affects the meaning of <I>local_free</I>
|
|
|
2689 |
and <I>last_local</I>.
|
|
|
2690 |
<P>
|
|
|
2691 |
<I>arg1</I> may be a zero <CODE>OFFSET</CODE>. In this case suppose
|
|
|
2692 |
the result is <I>p</I>. Then a subsequent use, in the same activation
|
|
|
2693 |
of the procedure, of<P>
|
|
|
2694 |
<I>local_free</I>(<I>offset_zero</I>(<I>alloca_alignment</I>), <I>p</I>)<P>
|
|
|
2695 |
will return the <I>alloca</I> stack to the state it was in immediately
|
|
|
2696 |
before the use of <I>local_alloc</I>.
|
|
|
2697 |
<P>
|
|
|
2698 |
Note that if a procedure which uses <I>local_alloc</I> is inlined,
|
|
|
2699 |
it may be necessary to use <I>local_free</I> to get the correct semantics.
|
|
|
2700 |
<P>
|
|
|
2701 |
See also <A HREF="spec10.html#22">section 7.12</A>.
|
|
|
2702 |
<P>
|
|
|
2703 |
|
|
|
2704 |
<H3>5.16.53. <A NAME=M132>local_alloc_check</A></H3>
|
|
|
2705 |
<B>Encoding number</B>: 53<P>
|
|
|
2706 |
<PRE>
|
|
|
2707 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
2708 |
-> EXP POINTER(<I>alloca_alignment</I>)
|
|
|
2709 |
</PRE>
|
|
|
2710 |
<P>
|
|
|
2711 |
If the <CODE>OFFSET</CODE> <I>arg1</I> can be accomodated within the
|
|
|
2712 |
limit of the local_alloc stack (see <A HREF="#M130">section 5.16.108</A>),
|
|
|
2713 |
the action is precisely the same as <I>local_alloc</I>.
|
|
|
2714 |
<P>
|
|
|
2715 |
If not, normal action is stopped and a TDF exception is raised with
|
|
|
2716 |
ERROR_CODE <I>stack_overflow</I>.
|
|
|
2717 |
<P>
|
|
|
2718 |
|
|
|
2719 |
<H3>5.16.54. <A NAME=M133>local_free</A></H3>
|
|
|
2720 |
<B>Encoding number</B>: 54<P>
|
|
|
2721 |
<PRE>
|
|
|
2722 |
<I>a</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
2723 |
<I>p</I>: EXP POINTER(<I>alloca_alignment</I>)
|
|
|
2724 |
-> EXP TOP
|
|
|
2725 |
</PRE>
|
|
|
2726 |
The <CODE>POINTER</CODE>, <I>p</I>, will be an original pointer to
|
|
|
2727 |
space allocated by <I>local_alloc</I> within the current call of the
|
|
|
2728 |
current procedure. It and all spaces allocated after it by <I>local_alloc</I>
|
|
|
2729 |
will no longer be used. This <CODE>POINTER</CODE> will have been created
|
|
|
2730 |
by <I>local_alloc</I> with the value of its <I>arg1</I> equal to the
|
|
|
2731 |
value of <I>a</I>.
|
|
|
2732 |
<P>
|
|
|
2733 |
Any subsequent use of pointers to the spaces no longer used will be
|
|
|
2734 |
undefined.
|
|
|
2735 |
<P>
|
|
|
2736 |
|
|
|
2737 |
<H3>5.16.55. <A NAME=M134>local_free_all</A></H3>
|
|
|
2738 |
<B>Encoding number</B>: 55<P>
|
|
|
2739 |
<PRE>
|
|
|
2740 |
-> EXP TOP
|
|
|
2741 |
</PRE>
|
|
|
2742 |
Every space allocated by <I>local_alloc</I> within the current call
|
|
|
2743 |
of the current procedure will no longer be used.
|
|
|
2744 |
<P>
|
|
|
2745 |
Any use of a pointer to space allocated before this operation within
|
|
|
2746 |
the current call of the current procedure is undefined.
|
|
|
2747 |
<P>
|
|
|
2748 |
Note that if a procedure which uses <I>local_free_all</I> is inlined,
|
|
|
2749 |
it may be necessary to use <I>local_free</I> to get the correct semantics.
|
|
|
2750 |
<P>
|
|
|
2751 |
|
|
|
2752 |
<H3>5.16.56. <A NAME=M135>long_jump</A></H3>
|
|
|
2753 |
<B>Encoding number</B>: 56<P>
|
|
|
2754 |
<PRE>
|
|
|
2755 |
<I>arg1</I>: EXP POINTER(<I>fa</I>)
|
|
|
2756 |
<I>arg2</I>: EXP POINTER({<I>code</I>})
|
|
|
2757 |
-> EXP BOTTOM
|
|
|
2758 |
</PRE>
|
|
|
2759 |
<I>arg1</I> will be a pointer produced by an application of
|
|
|
2760 |
<I>curent_env</I> in a currently active procedure.
|
|
|
2761 |
<P>
|
|
|
2762 |
The frame produced by <I>arg1</I> is reinstated as the current procedure.
|
|
|
2763 |
This frame will still be active. Evaluation recommences at the label
|
|
|
2764 |
given by <I>arg2</I>. This operation will only be used during the
|
|
|
2765 |
lifetime of that label.
|
|
|
2766 |
<P>
|
|
|
2767 |
Only <CODE>TAG</CODE>s declared to have <I>long_jump_access</I> will
|
|
|
2768 |
be defined at the re-entry.
|
|
|
2769 |
<P>
|
|
|
2770 |
If <I>arg2</I> delivers a null
|
|
|
2771 |
<CODE>POINTER(</CODE>{<I>code</I><CODE>})</CODE> the effect is undefined.
|
|
|
2772 |
<P>
|
|
|
2773 |
|
|
|
2774 |
<H3>5.16.57. <A NAME=M136>make_complex</A></H3>
|
|
|
2775 |
<B>Encoding number</B>: 57<P>
|
|
|
2776 |
<PRE>
|
|
|
2777 |
<I>c</I>: FLOATING_VARIETY
|
|
|
2778 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
2779 |
<I>arg2</I>: EXP FLOATING(<I>f</I>)
|
|
|
2780 |
-> EXP FLOATING(<I>c</I>)
|
|
|
2781 |
</PRE>
|
|
|
2782 |
<I>c</I> will be complex and derived from the same parameters as <I>f</I>.
|
|
|
2783 |
<P>
|
|
|
2784 |
Delivers a complex number with <I>arg1</I> delivering the real part
|
|
|
2785 |
and <I>arg2</I> the imaginary.
|
|
|
2786 |
<P>
|
|
|
2787 |
|
|
|
2788 |
<H3>5.16.58. <A NAME=M137>make_compound</A></H3>
|
|
|
2789 |
<B>Encoding number</B>: 58<P>
|
|
|
2790 |
<PRE>
|
|
|
2791 |
<I>arg1</I>: EXP OFFSET(<I>base</I>, <I>y</I>)
|
|
|
2792 |
<I>arg2</I>: LIST(EXP)
|
|
|
2793 |
-> EXP COMPOUND(<I>arg1</I>)
|
|
|
2794 |
</PRE>
|
|
|
2795 |
Let the <I>i</I>th component (<I>i</I> starts at one) of <I>arg2</I>
|
|
|
2796 |
be <I>x</I>[<I>i</I>]. The list may be empty.
|
|
|
2797 |
<P>
|
|
|
2798 |
The components <I>x</I>[2 * <I>k</I>] are values which are to be placed
|
|
|
2799 |
at <CODE>OFFSET</CODE>s given by <I>x</I>[2 * <I>k</I> - 1]. These
|
|
|
2800 |
<CODE>OFFSET</CODE>s will be constants and non-negative.
|
|
|
2801 |
<P>
|
|
|
2802 |
The <CODE>OFFSET</CODE> <I>x</I>[2 * <I>k</I> - 1] will have the
|
|
|
2803 |
<CODE>SHAPE</CODE> <CODE>OFFSET</CODE>(<I>z</I><I>k</I>,
|
|
|
2804 |
<I>alignment</I>(<I>shape</I>(<I>x</I>[2 * <I>k</I>]))), where
|
|
|
2805 |
<I>shape</I> gives the <CODE>SHAPE</CODE> of the component and
|
|
|
2806 |
<I>base</I> includes <I>z</I><I>k</I>.
|
|
|
2807 |
<P>
|
|
|
2808 |
<I>arg1</I> will be a constant non-negative <CODE>OFFSET</CODE>, see
|
|
|
2809 |
<A HREF="#M169">offset_pad</A>.
|
|
|
2810 |
<P>
|
|
|
2811 |
The values <I>x</I>[2 * <I>k</I> - 1] will be such that the components
|
|
|
2812 |
when in place either do not overlap or exactly coincide, in the sense
|
|
|
2813 |
that the <CODE>OFFSET</CODE>s are equal and the values have the same
|
|
|
2814 |
<CODE>SHAPE</CODE>. If they coincide the corresponding values <I>x</I>[2
|
|
|
2815 |
* <I>k</I>] will have <CODE>VARIETY SHAPE</CODE>s and will be <I>ored</I>
|
|
|
2816 |
together.
|
|
|
2817 |
<P>
|
|
|
2818 |
The <CODE>SHAPE</CODE> of a <I>x</I>[2 * <I>k</I>] component can be
|
|
|
2819 |
<CODE>TOP</CODE>. In this case the component is evaluated, but no
|
|
|
2820 |
value is placed at the corresponding <CODE>OFFSET</CODE>.
|
|
|
2821 |
<P>
|
|
|
2822 |
If <I>x[2 * k]</I> is a <CODE>BITFIELD</CODE> then <I>x[2 * k - 1]</I>,
|
|
|
2823 |
<I>shape(x[2 * k])</I> will be <I>variety-enclosed</I> (see
|
|
|
2824 |
<A HREF="spec10.html#66">section 7.24</A>).
|
|
|
2825 |
<P>
|
|
|
2826 |
|
|
|
2827 |
<H3>5.16.59. <A NAME=M138>make_floating</A></H3>
|
|
|
2828 |
<B>Encoding number</B>: 59<P>
|
|
|
2829 |
<PRE>
|
|
|
2830 |
<I>f</I>: FLOATING_VARIETY
|
|
|
2831 |
<I>rm</I>: ROUNDING_MODE
|
|
|
2832 |
<I>negative</I>: BOOL
|
|
|
2833 |
<I>mantissa</I>: STRING<I>(k, n)</I>
|
|
|
2834 |
<I>base</I>: NAT
|
|
|
2835 |
<I>exponent</I>: SIGNED_NAT
|
|
|
2836 |
-> EXP FLOATING(<I>f</I>)
|
|
|
2837 |
</PRE>
|
|
|
2838 |
<I>f</I> will not be complex.
|
|
|
2839 |
<P>
|
|
|
2840 |
<I>mantissa</I> will be a <CODE>STRING</CODE> of 8-bit integers, each
|
|
|
2841 |
of which is either 46 or is greater than or equal to 48. Those values,
|
|
|
2842 |
<I>c</I>, which lie between 48 and 63 will represent the digit <I>c</I>-48.
|
|
|
2843 |
A decimal point is represented by 46.
|
|
|
2844 |
<P>
|
|
|
2845 |
The <CODE>BOOL</CODE> <I>negative</I> determines the sign of the result,
|
|
|
2846 |
if true the result will be negative, if false, positive.
|
|
|
2847 |
<P>
|
|
|
2848 |
A floating point number, <I>mantissa</I>*(<I>base</I><SUP><I>exponent</I></SUP>)
|
|
|
2849 |
is created and rounded to the representation of <I>f</I> as specified
|
|
|
2850 |
by <I>rm</I>. <I>rm</I> will not be <I>round_as_state</I>. <I>mantissa</I>
|
|
|
2851 |
is read as a sequence of digits to base <I>base</I> and may contain
|
|
|
2852 |
one point symbol.
|
|
|
2853 |
<P>
|
|
|
2854 |
<I>base</I> will be one of the numbers 2, 4, 8, 10, 16. Note that
|
|
|
2855 |
in base 16 the digit 10 is represented by the character number 58
|
|
|
2856 |
etc.
|
|
|
2857 |
<P>
|
|
|
2858 |
The result will lie in <I>f</I>.
|
|
|
2859 |
<P>
|
|
|
2860 |
|
|
|
2861 |
<H3>5.16.60. <A NAME=M139>make_general_proc</A></H3>
|
|
|
2862 |
<!-- BREAK 4 -->
|
|
|
2863 |
<B>Encoding number</B>: 60<P>
|
|
|
2864 |
<PRE>
|
|
|
2865 |
<I>result_shape</I>: SHAPE
|
|
|
2866 |
<I>prcprops</I>: OPTION(PROCPROPS)
|
|
|
2867 |
<I>caller_intro</I>: LIST(TAGSHACC)
|
|
|
2868 |
<I>callee_intro</I>: LIST(TAGSHACC)
|
|
|
2869 |
<I>body</I>: EXP BOTTOM
|
|
|
2870 |
-> EXP PROC
|
|
|
2871 |
</PRE>
|
|
|
2872 |
Evaluation of <I>make_general_proc</I> delivers a <CODE>PROC</CODE>.
|
|
|
2873 |
When this procedure is applied to parameters using <I>apply_general_proc</I>,
|
|
|
2874 |
space is allocated to hold the actual values of the parameters <I>caller_intro
|
|
|
2875 |
</I> and <I>callee_intro</I>
|
|
|
2876 |
. The values produced by the actual parameters are used to initialise
|
|
|
2877 |
these spaces. Then <I>body</I> is evaluated. During this evaluation
|
|
|
2878 |
the <CODE>TAG</CODE>s in <I>caller_intro</I> and <I>callee_intro</I>
|
|
|
2879 |
are bound to original <CODE>POINTER</CODE>s to these spaces. The lifetime
|
|
|
2880 |
of these <CODE>TAG</CODE>s is the evaluation of <I>body</I>.
|
|
|
2881 |
<P>
|
|
|
2882 |
The <CODE>SHAPE</CODE> of <I>body</I> will be <CODE>BOTTOM</CODE>.
|
|
|
2883 |
<I>caller_intro</I> and <I>callee_intro</I> may be empty.
|
|
|
2884 |
<P>
|
|
|
2885 |
The <CODE>TAG</CODE>s introduced in the parameters will not be reused
|
|
|
2886 |
within the current <CODE>UNIT</CODE>.
|
|
|
2887 |
<P>
|
|
|
2888 |
The <CODE>SHAPE</CODE>s in the parameters specify the <CODE>SHAPE</CODE>
|
|
|
2889 |
of the corresponding <CODE>TAG</CODE>s.
|
|
|
2890 |
<P>
|
|
|
2891 |
The <CODE>OPTION(ACCESS)</CODE> (in <I>params_intro</I>) specifies
|
|
|
2892 |
the <CODE>ACCESS</CODE> properties of the corresponding parameter,
|
|
|
2893 |
just as for a variable declaration.
|
|
|
2894 |
<P>
|
|
|
2895 |
In <I>body</I> the only <CODE>TAG</CODE>s which may be used as an
|
|
|
2896 |
argument of <I>obtain_tag</I> are those which are declared by
|
|
|
2897 |
<I>identify</I> or <I>variable</I> constructions in <I>body</I> and
|
|
|
2898 |
which are in scope, or <CODE>TAG</CODE>s which are declared by
|
|
|
2899 |
<I>make_id_tagdef</I>, <I>make_var_tagdef</I> or <I>common_tagdef</I>
|
|
|
2900 |
or are in <I>caller_intro</I> or <I>callee_intro</I>. If a <I>make_proc</I>
|
|
|
2901 |
occurs in <I>body</I> its <CODE>TAG</CODE>s are not in scope.
|
|
|
2902 |
<P>
|
|
|
2903 |
The argument of every <I>return</I> or <I>untidy_return</I> construction
|
|
|
2904 |
in <I>body</I> will have <CODE>SHAPE</CODE> <I>result_shape</I>. Every
|
|
|
2905 |
<I>apply_general_proc</I> using the procedure will specify the
|
|
|
2906 |
<CODE>SHAPE</CODE> of its result to be <I>result_shape</I>.
|
|
|
2907 |
<P>
|
|
|
2908 |
The presence or absence of each of the <CODE>PROCPROPS</CODE>
|
|
|
2909 |
<I>var_callers</I>, <I>var_callees, check_stack</I> and <I>untidy</I>
|
|
|
2910 |
in
|
|
|
2911 |
<I>prcprops</I> will be reflected in every <I>apply_general_proc</I>
|
|
|
2912 |
or
|
|
|
2913 |
<I>tail_call</I> on this procedure.
|
|
|
2914 |
<P>
|
|
|
2915 |
The definition of the canonical ordering of the evaluation of
|
|
|
2916 |
<I>apply_general_proc</I> gives the definition of these
|
|
|
2917 |
<CODE>PROCPROPS</CODE>.
|
|
|
2918 |
<P>
|
|
|
2919 |
If <I>prcprocs</I> contains <I>check_stack</I>, a TDF exception will
|
|
|
2920 |
be raised if the static space required for the procedure call (in
|
|
|
2921 |
the sense of <I>env_size</I>) would exceed the limit given by
|
|
|
2922 |
<I>set_stack_limit</I>.
|
|
|
2923 |
<P>
|
|
|
2924 |
If <I>prcprops</I> contains <I>no_long_jump_dest</I>, the body of
|
|
|
2925 |
the procedure will never contain the destination label of a
|
|
|
2926 |
<I>long_jump</I>.
|
|
|
2927 |
<P>
|
|
|
2928 |
For notes on the intended implementation of procedures see
|
|
|
2929 |
<A HREF="spec10.html#18">section 7.9</A>.
|
|
|
2930 |
<P>
|
|
|
2931 |
|
|
|
2932 |
<H3>5.16.61. <A NAME=M141>make_int</A></H3>
|
|
|
2933 |
<B>Encoding number</B>: 61<P>
|
|
|
2934 |
<PRE>
|
|
|
2935 |
<I>v</I>: VARIETY
|
|
|
2936 |
<I>value</I>: SIGNED_NAT
|
|
|
2937 |
-> EXP INTEGER(<I>v</I>)
|
|
|
2938 |
</PRE>
|
|
|
2939 |
An integer value is delivered of which the value is given by <I>value</I>,
|
|
|
2940 |
and the <CODE>VARIETY</CODE> by <I>v</I>. The <CODE>SIGNED_NAT</CODE>
|
|
|
2941 |
<I>value</I> will lie between the bounds of <I>v</I>.
|
|
|
2942 |
<P>
|
|
|
2943 |
|
|
|
2944 |
<H3>5.16.62. <A NAME=M142>make_local_lv</A></H3>
|
|
|
2945 |
<B>Encoding number</B>: 62<P>
|
|
|
2946 |
<PRE>
|
|
|
2947 |
<I>lab</I>: LABEL
|
|
|
2948 |
-> EXP POINTER(<I>{code</I>})
|
|
|
2949 |
</PRE>
|
|
|
2950 |
A <CODE>POINTER(</CODE><I>{code</I><CODE>})</CODE> <I>lv</I> is created
|
|
|
2951 |
and delivered. It can be used as an argument to <I>goto_local_lv</I>
|
|
|
2952 |
or <I>long_jump</I>. If and when one of these is evaluated with <I>lv</I>
|
|
|
2953 |
as an argument, control will pass to <I>lab</I>.
|
|
|
2954 |
<P>
|
|
|
2955 |
|
|
|
2956 |
<H3>5.16.63. <A NAME=M143>make_nof</A></H3>
|
|
|
2957 |
<B>Encoding number</B>: 63<P>
|
|
|
2958 |
<PRE>
|
|
|
2959 |
<I>arg1</I>: LIST(EXP)
|
|
|
2960 |
-> EXP NOF(<I>n</I>, <I>s</I>)
|
|
|
2961 |
</PRE>
|
|
|
2962 |
Creates an array of <I>n</I> values of <CODE>SHAPE</CODE> <I>s</I>,
|
|
|
2963 |
containing the given values produced by evaluating the members of
|
|
|
2964 |
<I>arg1</I> in the same order as they occur in the list.
|
|
|
2965 |
<P>
|
|
|
2966 |
<I>n</I> will not be zero.
|
|
|
2967 |
<P>
|
|
|
2968 |
|
|
|
2969 |
<H3>5.16.64. <A NAME=M144>make_nof_int</A></H3>
|
|
|
2970 |
<B>Encoding number</B>: 64<P>
|
|
|
2971 |
<PRE>
|
|
|
2972 |
<I>v</I>: VARIETY
|
|
|
2973 |
<I>str</I>: STRING<I>(k, n)</I>
|
|
|
2974 |
-> EXP NOF(<I>n</I>, INTEGER(<I>v</I>))
|
|
|
2975 |
</PRE>
|
|
|
2976 |
An <CODE>NOF INTEGER</CODE> is delivered. The conversions are carried
|
|
|
2977 |
out as if the elements of <I>str</I> were
|
|
|
2978 |
<CODE>INTEGER</CODE>(<I>var_limits</I>(0, 2<SUP><I>k</I></SUP>-1)).
|
|
|
2979 |
<I>n</I> may be zero.
|
|
|
2980 |
<P>
|
|
|
2981 |
|
|
|
2982 |
<H3>5.16.65. <A NAME=M145>make_null_local_lv</A></H3>
|
|
|
2983 |
<B>Encoding number</B>: 65<P>
|
|
|
2984 |
<PRE>
|
|
|
2985 |
-> EXP POINTER({<I>code</I>})
|
|
|
2986 |
</PRE>
|
|
|
2987 |
Makes a null <CODE>POINTER</CODE>({<I>code</I>}) which can be detected
|
|
|
2988 |
by <I>pointer_test</I>. The effect of <I>goto_local_lv</I> or
|
|
|
2989 |
<I>long_jump</I> applied to this value is undefined.
|
|
|
2990 |
<P>
|
|
|
2991 |
All null <CODE>POINTER</CODE>({<I>code</I>}) are equal to each other
|
|
|
2992 |
and unequal to any other <CODE>POINTER</CODE>s.
|
|
|
2993 |
<P>
|
|
|
2994 |
|
|
|
2995 |
<H3>5.16.66. <A NAME=M146>make_null_proc</A></H3>
|
|
|
2996 |
<B>Encoding number</B>: 66<P>
|
|
|
2997 |
<PRE>
|
|
|
2998 |
-> EXP PROC
|
|
|
2999 |
</PRE>
|
|
|
3000 |
A null <CODE>PROC</CODE> is created and delivered. The null
|
|
|
3001 |
<CODE>PROC</CODE> may be tested for by using <I>proc_test</I>. The
|
|
|
3002 |
effect of using it as the first argument of <I>apply_proc</I> is undefined.
|
|
|
3003 |
<P>
|
|
|
3004 |
All null <CODE>PROC</CODE> are equal to each other and unequal to
|
|
|
3005 |
any other <CODE>PROC</CODE>.
|
|
|
3006 |
<P>
|
|
|
3007 |
|
|
|
3008 |
<H3>5.16.67. <A NAME=M147>make_null_ptr</A></H3>
|
|
|
3009 |
<B>Encoding number</B>: 67<P>
|
|
|
3010 |
<PRE>
|
|
|
3011 |
<I>a</I>: ALIGNMENT
|
|
|
3012 |
-> EXP POINTER(<I>a</I>)
|
|
|
3013 |
</PRE>
|
|
|
3014 |
A null <CODE>POINTER</CODE>(<I>a</I>) is created and delivered. The
|
|
|
3015 |
null <CODE>POINTER</CODE> may be tested for by <I>pointer_test</I>.
|
|
|
3016 |
<P>
|
|
|
3017 |
<I>a</I> will not include <I>code</I>.
|
|
|
3018 |
<P>
|
|
|
3019 |
All null <CODE>POINTER</CODE>(<I>x</I>) are equal to each other and
|
|
|
3020 |
unequal to any other <CODE>POINTER</CODE>(<I>x</I>).
|
|
|
3021 |
<P>
|
|
|
3022 |
|
|
|
3023 |
<H3>5.16.68. <A NAME=M148>make_proc</A></H3>
|
|
|
3024 |
<!-- BREAK 3 -->
|
|
|
3025 |
<B>Encoding number</B>: 68<P>
|
|
|
3026 |
<PRE>
|
|
|
3027 |
<I>result_shape</I>: SHAPE
|
|
|
3028 |
<I>params_intro</I>: LIST(TAGSHACC)
|
|
|
3029 |
<I>var_intro</I>: OPTION(TAGACC)
|
|
|
3030 |
<I>body</I>: EXP BOTTOM
|
|
|
3031 |
-> EXP PROC
|
|
|
3032 |
</PRE>
|
|
|
3033 |
Evaluation of <I>make_proc</I> delivers a
|
|
|
3034 |
<CODE>PROC</CODE>. When this procedure is applied to parameters using
|
|
|
3035 |
<I>apply_proc</I>, space is allocated to hold the actual values of
|
|
|
3036 |
the parameters <I>params_intro</I> and <I>var_intro</I> (if present).
|
|
|
3037 |
The values produced by the actual parameters are used to initialise
|
|
|
3038 |
these spaces. Then <I>body</I> is evaluated. During this evaluation
|
|
|
3039 |
the
|
|
|
3040 |
<CODE>TAG</CODE>s in <I>params_intro</I> and <I>var_intro</I> are
|
|
|
3041 |
bound to original <CODE>POINTER</CODE>s to these spaces. The lifetime
|
|
|
3042 |
of these
|
|
|
3043 |
<CODE>TAG</CODE>s is the evaluation of <I>body</I>.
|
|
|
3044 |
<P>
|
|
|
3045 |
If <I>var_intro</I> is present, it may be used for one of two purposes,
|
|
|
3046 |
with different consequences for corresponding uses of <I>apply_proc</I>.
|
|
|
3047 |
See <A HREF="spec10.html#18">section 7.9</A>. The
|
|
|
3048 |
<CODE>ALIGNMENT</CODE>, <I>var_param_alignment</I>, includes the set
|
|
|
3049 |
union of all the <CODE>ALIGNMENT</CODE>s which can be produced by
|
|
|
3050 |
<I>alignment</I> from any <CODE>SHAPE</CODE>. Note that <I>var_intro</I>
|
|
|
3051 |
does not contain an <CODE>ACCESS</CODE> component and so cannot be
|
|
|
3052 |
marked <I>visible</I>. Hence it is not a possible argument of
|
|
|
3053 |
<I>env_offset</I>. If present, <I>var_intro</I> is an original pointer.
|
|
|
3054 |
<P>
|
|
|
3055 |
The <CODE>SHAPE</CODE> of <I>body</I> will be <CODE>BOTTOM</CODE>.
|
|
|
3056 |
<I>params_intro</I> may be empty.
|
|
|
3057 |
<P>
|
|
|
3058 |
The <CODE>TAG</CODE>s introduced in the parameters will not be reused
|
|
|
3059 |
within the current <CODE>UNIT</CODE>.
|
|
|
3060 |
<P>
|
|
|
3061 |
The <CODE>SHAPE</CODE>s in the parameters specify the <CODE>SHAPE</CODE>
|
|
|
3062 |
of the corresponding <CODE>TAG</CODE>s.
|
|
|
3063 |
<P>
|
|
|
3064 |
The <CODE>OPTION(ACCESS</CODE>) (in <I>params_intro</I>) specifies
|
|
|
3065 |
the <CODE>ACCESS</CODE> properties of the corresponding parameter,
|
|
|
3066 |
just as for a variable declaration.
|
|
|
3067 |
<P>
|
|
|
3068 |
In <I>body</I> the only <CODE>TAG</CODE>s which may be used as an
|
|
|
3069 |
argument of <I>obtain_tag</I> are those which are declared by
|
|
|
3070 |
<I>identify</I> or <I>variable</I> constructions in <I>body</I> and
|
|
|
3071 |
which are in scope, or <CODE>TAG</CODE>s which are declared by
|
|
|
3072 |
<I>make_id_tagdef</I>, <I>make_var_tagdef</I> or <I>common_tagdef</I>
|
|
|
3073 |
or are in <I>params_intro</I> or <I>var_intro</I>. If a <I>make_proc</I>
|
|
|
3074 |
occurs in <I>body</I> its <CODE>TAG</CODE>s are not in scope.
|
|
|
3075 |
<P>
|
|
|
3076 |
The argument of every <I>return</I> construction in <I>body</I> will
|
|
|
3077 |
have <CODE>SHAPE</CODE> <I>result_shape</I>. Every <I>apply_proc</I>
|
|
|
3078 |
using the procedure will specify the <CODE>SHAPE</CODE> of it result
|
|
|
3079 |
to be <I>result_shape</I>.
|
|
|
3080 |
<P>
|
|
|
3081 |
For notes on the intended implementation of procedures see
|
|
|
3082 |
<A HREF="spec10.html#18">section 7.9</A>.
|
|
|
3083 |
<P>
|
|
|
3084 |
|
|
|
3085 |
<H3>5.16.69. <A NAME=M150>make_stack_limit</A></H3>
|
|
|
3086 |
<B>Encoding number</B>: 116<P>
|
|
|
3087 |
<PRE>
|
|
|
3088 |
<I>stack_base</I>: EXP POINTER(<I>fa</I>)
|
|
|
3089 |
<I>frame_size</I>: EXP OFFSET(<I>locals_alignment</I>, <I>x</I>)
|
|
|
3090 |
<I>alloc_size</I>: EXP OFFSET(<I>alloca_alignment</I>, <I>y</I>)
|
|
|
3091 |
-> EXP POINTER(<I>fb</I>)
|
|
|
3092 |
</PRE>
|
|
|
3093 |
This creates a POINTER suitable for use with <I>set_stack_limit</I>.
|
|
|
3094 |
<P>
|
|
|
3095 |
<I>fa</I> and <I>fb</I> will include <I>locals_alignment</I> and,
|
|
|
3096 |
if
|
|
|
3097 |
<I>alloc_size</I> is not the zero offset, will also contain
|
|
|
3098 |
<I>alloca_alignment</I>.
|
|
|
3099 |
<P>
|
|
|
3100 |
The result will be the same as if given by:<BR>
|
|
|
3101 |
Assume <I>stack_base</I> is the current frame-pointer as given by
|
|
|
3102 |
<I>current_env</I> in a hypothetical procedure P with <I>env_size</I>
|
|
|
3103 |
equal to <I>frame_size</I> and which has generated <I>alloc_size</I>
|
|
|
3104 |
by a <I>local_alloc</I>. If P then calls Q, the result will be the
|
|
|
3105 |
same as that of a <I>current_env</I> performed immediately in the
|
|
|
3106 |
body of Q.<BR>
|
|
|
3107 |
If the following construction is performed:<BR>
|
|
|
3108 |
set_stack_limit(make_stack_limit(current_env, F, A))<BR>
|
|
|
3109 |
the frame space and local_alloc space that would be available for
|
|
|
3110 |
use by this supposed call of Q will not be reused by procedure calls
|
|
|
3111 |
with <I>check_stack</I> or uses of <I>local_alloc_check</I> after
|
|
|
3112 |
the <I>set_stack_limit</I>. Any attempt to do so will raise a TDF
|
|
|
3113 |
exception, <I>stack_overflow</I>.
|
|
|
3114 |
<P>
|
|
|
3115 |
|
|
|
3116 |
<H3>5.16.70. <A NAME=M151>make_top</A></H3>
|
|
|
3117 |
<B>Encoding number</B>: 69<P>
|
|
|
3118 |
<PRE>
|
|
|
3119 |
-> EXP TOP
|
|
|
3120 |
</PRE>
|
|
|
3121 |
<I>make_top</I> delivers a value of <CODE>SHAPE TOP</CODE>
|
|
|
3122 |
(i.e. <I>void</I>).
|
|
|
3123 |
<P>
|
|
|
3124 |
|
|
|
3125 |
<H3>5.16.71. <A NAME=M152>make_value</A></H3>
|
|
|
3126 |
<B>Encoding number</B>: 70<P>
|
|
|
3127 |
<PRE>
|
|
|
3128 |
<I>s</I>: SHAPE
|
|
|
3129 |
-> EXP <I>s</I>
|
|
|
3130 |
</PRE>
|
|
|
3131 |
This <CODE>EXP</CODE> creates some value with the representation of
|
|
|
3132 |
the <CODE>SHAPE</CODE> <I>s</I>. This value will have the correct
|
|
|
3133 |
size, but its representation is not specified. It can be assigned,
|
|
|
3134 |
be the result of a <I>contents</I>, a parameter or result of a procedure,
|
|
|
3135 |
or the result of any construction (like <I>sequence</I>) which delivers
|
|
|
3136 |
the value delivered by an internal <CODE>EXP</CODE>. But if it is
|
|
|
3137 |
used for arithmetic or as a <CODE>POINTER</CODE> for taking <I>contents</I>
|
|
|
3138 |
or <I>add_to_ptr</I> etc. the effect is undefined.
|
|
|
3139 |
<P>
|
|
|
3140 |
Installers will usually be able to implement this operation by producing
|
|
|
3141 |
no code.
|
|
|
3142 |
<P>
|
|
|
3143 |
<I>Note that a floating point NaN is a possible value for this purpose.</I>
|
|
|
3144 |
<P>
|
|
|
3145 |
The <CODE>SHAPE</CODE> <I>s</I> will not be <CODE>BOTTOM</CODE>.
|
|
|
3146 |
<P>
|
|
|
3147 |
|
|
|
3148 |
<H3>5.16.72. <A NAME=M153>maximum</A></H3>
|
|
|
3149 |
<B>Encoding number</B>: 71<P>
|
|
|
3150 |
<PRE>
|
|
|
3151 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3152 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3153 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3154 |
</PRE>
|
|
|
3155 |
The arguments will be evaluated and the maximum of the values delivered
|
|
|
3156 |
is the result.
|
|
|
3157 |
<P>
|
|
|
3158 |
|
|
|
3159 |
<H3>5.16.73. <A NAME=M154>minimum</A></H3>
|
|
|
3160 |
<B>Encoding number</B>: 72<P>
|
|
|
3161 |
<PRE>
|
|
|
3162 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3163 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3164 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3165 |
</PRE>
|
|
|
3166 |
The arguments will be evaluated and the minimum of the values delivered
|
|
|
3167 |
is the result.
|
|
|
3168 |
<P>
|
|
|
3169 |
|
|
|
3170 |
<H3>5.16.74. <A NAME=M155>minus</A></H3>
|
|
|
3171 |
<B>Encoding number</B>: 73<P>
|
|
|
3172 |
<PRE>
|
|
|
3173 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3174 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3175 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3176 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3177 |
</PRE>
|
|
|
3178 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3179 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
3180 |
The difference <I>a</I>-<I>b</I> is delivered as the result of the
|
|
|
3181 |
construct, with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
3182 |
<P>
|
|
|
3183 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
3184 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
3185 |
in the way specified by <I>ov_err</I>.
|
|
|
3186 |
<P>
|
|
|
3187 |
|
|
|
3188 |
<H3>5.16.75. <A NAME=M156>move_some</A></H3>
|
|
|
3189 |
<B>Encoding number</B>: 74<P>
|
|
|
3190 |
<PRE>
|
|
|
3191 |
<I>md</I>: TRANSFER_MODE
|
|
|
3192 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
3193 |
<I>arg2</I>: EXP POINTER(<I>y</I>)
|
|
|
3194 |
<I>arg3</I>: EXP OFFSET(<I>z</I>, <I>t</I>)
|
|
|
3195 |
-> EXP TOP
|
|
|
3196 |
</PRE>
|
|
|
3197 |
The arguments are evaluated to produce <I>p1</I>, <I>p2</I>, and
|
|
|
3198 |
<I>sz</I> respectively. A quantity of data measured by <I>sz</I> in
|
|
|
3199 |
the space indicated by <I>p1</I> is moved to the space indicated by
|
|
|
3200 |
<I>p2</I>. The operation will be carried out as specified by the
|
|
|
3201 |
<CODE>TRANSFER_MODE</CODE> (q.v.).
|
|
|
3202 |
<P>
|
|
|
3203 |
<I>x</I> will include <I>z</I> and <I>y</I> will include <I>z</I>.
|
|
|
3204 |
<P>
|
|
|
3205 |
<I>sz</I> will be a non-negative <CODE>OFFSET</CODE>, see
|
|
|
3206 |
<A HREF="#M169">offset_pad</A>.
|
|
|
3207 |
<P>
|
|
|
3208 |
If the spaces of size <I>sz</I> to which <I>p1</I> and <I>p2</I> point
|
|
|
3209 |
do not lie entirely within the spaces indicated by the original pointers
|
|
|
3210 |
from which they are derived, the effect of the operation is undefined.
|
|
|
3211 |
<P>
|
|
|
3212 |
If the value delivered by <I>arg1</I> or <I>arg2</I> is a null pointer
|
|
|
3213 |
the effect is undefined.
|
|
|
3214 |
<P>
|
|
|
3215 |
See <A HREF="spec10.html#48">Overlapping</A>.
|
|
|
3216 |
<P>
|
|
|
3217 |
|
|
|
3218 |
<H3>5.16.76. <A NAME=M157>mult</A></H3>
|
|
|
3219 |
<B>Encoding number</B>: 75<P>
|
|
|
3220 |
<PRE>
|
|
|
3221 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3222 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3223 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3224 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3225 |
</PRE>
|
|
|
3226 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3227 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
3228 |
The product <I>a</I>*<I>b</I> is delivered as the result of the construct,
|
|
|
3229 |
with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
3230 |
<P>
|
|
|
3231 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
3232 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
3233 |
in the way specified by <I>ov_err</I>.
|
|
|
3234 |
<P>
|
|
|
3235 |
|
|
|
3236 |
<H3>5.16.77. <A NAME=M158>n_copies</A></H3>
|
|
|
3237 |
<B>Encoding number</B>: 76<P>
|
|
|
3238 |
<PRE>
|
|
|
3239 |
<I>n</I>: NAT
|
|
|
3240 |
<I>arg1</I>: EXP <I>x</I>
|
|
|
3241 |
-> EXP NOF(<I>n</I>, <I>x</I>)
|
|
|
3242 |
</PRE>
|
|
|
3243 |
<I>arg1</I> is evaluated and an <CODE>NOF</CODE> value is delivered
|
|
|
3244 |
which contains <I>n</I> copies of this value. <I>n</I> can be zero
|
|
|
3245 |
or one or greater.
|
|
|
3246 |
<P>
|
|
|
3247 |
Producers are encouraged to use <I>n_copies</I> to initialise arrays
|
|
|
3248 |
of known size.
|
|
|
3249 |
<P>
|
|
|
3250 |
|
|
|
3251 |
<H3>5.16.78. <A NAME=M159>negate</A></H3>
|
|
|
3252 |
<B>Encoding number</B>: 77<P>
|
|
|
3253 |
<PRE>
|
|
|
3254 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3255 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3256 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3257 |
</PRE>
|
|
|
3258 |
<I>arg1</I> is evaluated and will produce an integer value, <I>a</I>.
|
|
|
3259 |
The value -<I>a</I> is delivered as the result of the construct, with
|
|
|
3260 |
the same <CODE>SHAPE</CODE> as the argument.
|
|
|
3261 |
<P>
|
|
|
3262 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
3263 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
3264 |
in the way specified by <I>ov_err</I>.
|
|
|
3265 |
<P>
|
|
|
3266 |
|
|
|
3267 |
<H3>5.16.79. <A NAME=M160>not</A></H3>
|
|
|
3268 |
<B>Encoding number</B>: 78<P>
|
|
|
3269 |
<PRE>
|
|
|
3270 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3271 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3272 |
</PRE>
|
|
|
3273 |
The argument is evaluated producing an integer value, of
|
|
|
3274 |
<CODE>VARIETY</CODE>, <I>v</I>. The result is the bitwise <I>not</I>
|
|
|
3275 |
of this value in the representing <CODE>VARIETY</CODE>. The result
|
|
|
3276 |
is delivered as the result of the construct, with the same
|
|
|
3277 |
<CODE>SHAPE</CODE> as the arguments.
|
|
|
3278 |
<P>
|
|
|
3279 |
See <A HREF="spec10.html#51">Representing integers</A>.
|
|
|
3280 |
<P>
|
|
|
3281 |
|
|
|
3282 |
<H3>5.16.80. <A NAME=M161>obtain_tag</A></H3>
|
|
|
3283 |
<B>Encoding number</B>: 79<P>
|
|
|
3284 |
<PRE>
|
|
|
3285 |
<I>t</I>: TAG <I>x</I>
|
|
|
3286 |
-> EXP <I>x</I>
|
|
|
3287 |
</PRE>
|
|
|
3288 |
The value with which the <CODE>TAG</CODE> <I>t</I> is bound is delivered.
|
|
|
3289 |
The <CODE>SHAPE</CODE> of the result is the <CODE>SHAPE</CODE> of
|
|
|
3290 |
the value with which the <CODE>TAG</CODE> is bound.
|
|
|
3291 |
<P>
|
|
|
3292 |
|
|
|
3293 |
<H3>5.16.81. <A NAME=M162>offset_add</A></H3>
|
|
|
3294 |
<B>Encoding number</B>: 80<P>
|
|
|
3295 |
<PRE>
|
|
|
3296 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
3297 |
<I>arg2</I>: EXP OFFSET(<I>z</I>, <I>t</I>)
|
|
|
3298 |
-> EXP OFFSET(<I>x</I>, <I>t</I>)
|
|
|
3299 |
</PRE>
|
|
|
3300 |
The two arguments deliver <CODE>OFFSET</CODE>s. The result is the
|
|
|
3301 |
sum of these <CODE>OFFSET</CODE>s, as an <CODE>OFFSET</CODE>.
|
|
|
3302 |
<P>
|
|
|
3303 |
<I>y</I> will include <I>z</I>.
|
|
|
3304 |
<P>
|
|
|
3305 |
<I>The effect of the constraint "y will include z" is that,
|
|
|
3306 |
in the simple representation of pointer arithmetic, this operation
|
|
|
3307 |
can be represented by addition. offset_add can lose information, so
|
|
|
3308 |
that offset_subtract does not have the usual relation with it.</I>
|
|
|
3309 |
<P>
|
|
|
3310 |
|
|
|
3311 |
<H3>5.16.82. <A NAME=M163>offset_div</A></H3>
|
|
|
3312 |
<B>Encoding number</B>: 81<P>
|
|
|
3313 |
<PRE>
|
|
|
3314 |
<I>v</I>: VARIETY
|
|
|
3315 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3316 |
<I>arg2</I>: EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3317 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3318 |
</PRE>
|
|
|
3319 |
The two arguments deliver <CODE>OFFSET</CODE>s, <I>a</I> and <I>b</I>.
|
|
|
3320 |
The result is <I>a/b</I>, as an <CODE>INTEGER</CODE> of <CODE>VARIETY</CODE>,
|
|
|
3321 |
<I>v</I>. Division is interpreted in the same sense (with respect
|
|
|
3322 |
to remainder) as in <I>div0</I>.
|
|
|
3323 |
<P>
|
|
|
3324 |
The value produced by <I>arg2</I> will be non-zero.
|
|
|
3325 |
<P>
|
|
|
3326 |
|
|
|
3327 |
<H3>5.16.83. <A NAME=M164>offset_div_by_int</A></H3>
|
|
|
3328 |
<B>Encoding number</B>: 82<P>
|
|
|
3329 |
<PRE>
|
|
|
3330 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3331 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3332 |
-> EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3333 |
</PRE>
|
|
|
3334 |
The result is the <CODE>OFFSET</CODE> produced by <I>arg1</I> divided
|
|
|
3335 |
by <I>arg2</I>, as an <CODE>OFFSET</CODE>(<I>x</I>, <I>x</I>).
|
|
|
3336 |
<P>
|
|
|
3337 |
The value produced by <I>arg2</I> will be greater than zero.
|
|
|
3338 |
<P>
|
|
|
3339 |
The following identity will apply for all A and n:<P>
|
|
|
3340 |
<I>offset_mult</I>(<I>offset_div_by_int</I>(A, n), n) = A<P>
|
|
|
3341 |
<P>
|
|
|
3342 |
|
|
|
3343 |
<H3>5.16.84. <A NAME=M165>offset_max</A></H3>
|
|
|
3344 |
<B>Encoding number</B>: 83<P>
|
|
|
3345 |
<PRE>
|
|
|
3346 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
3347 |
<I>arg2</I>: EXP OFFSET(<I>z</I>, <I>y</I>)
|
|
|
3348 |
-> EXP OFFSET(<I>unite_alignments</I>(<I>x</I>, <I>z</I>), <I>y</I>)
|
|
|
3349 |
</PRE>
|
|
|
3350 |
The two arguments deliver <CODE>OFFSET</CODE>s. The result is the
|
|
|
3351 |
maximum of these <CODE>OFFSET</CODE>s, as an <CODE>OFFSET</CODE>.
|
|
|
3352 |
<P>
|
|
|
3353 |
See <A HREF="spec10.html#31">Comparison of pointers and offsets</A>.
|
|
|
3354 |
<P>
|
|
|
3355 |
<I>In the simple memory model this operation is represented by maximum.
|
|
|
3356 |
The constraint that the second <CODE>ALIGNMENT</CODE> parameters are
|
|
|
3357 |
both y is to permit the representation of <CODE>OFFSET</CODE>s in
|
|
|
3358 |
installers by a simple homomorphism.</I>
|
|
|
3359 |
<P>
|
|
|
3360 |
|
|
|
3361 |
<H3>5.16.85. <A NAME=M166>offset_mult</A></H3>
|
|
|
3362 |
<B>Encoding number</B>: 84<P>
|
|
|
3363 |
<PRE>
|
|
|
3364 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3365 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3366 |
-> EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3367 |
</PRE>
|
|
|
3368 |
The first argument gives an <CODE>OFFSET</CODE>, <I>off</I>, and the
|
|
|
3369 |
second an integer, <I>n</I>. The result is the product of these, as
|
|
|
3370 |
an offset.
|
|
|
3371 |
<P>
|
|
|
3372 |
The result shall be equal to <I>offset_adding off n</I>
|
|
|
3373 |
times to <I>offset_zero</I>(<I>x</I>).
|
|
|
3374 |
<P>
|
|
|
3375 |
|
|
|
3376 |
<H3>5.16.86. <A NAME=M167>offset_negate</A></H3>
|
|
|
3377 |
<B>Encoding number</B>: 85<P>
|
|
|
3378 |
<PRE>
|
|
|
3379 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3380 |
-> EXP OFFSET(<I>x</I>, <I>x</I>)
|
|
|
3381 |
</PRE>
|
|
|
3382 |
The inverse of the argument is delivered.
|
|
|
3383 |
<P>
|
|
|
3384 |
<I>In the simple memory model this can be represented by negate.</I>
|
|
|
3385 |
<P>
|
|
|
3386 |
|
|
|
3387 |
<H3>5.16.87. <A NAME=M169>offset_pad</A></H3>
|
|
|
3388 |
<B>Encoding number</B>: 86<P>
|
|
|
3389 |
<PRE>
|
|
|
3390 |
<I>a</I>: ALIGNMENT
|
|
|
3391 |
<I>arg1</I>: EXP OFFSET(<I>z</I>, <I>t</I>)
|
|
|
3392 |
-> EXP OFFSET(<I>unite_alignments</I>(<I>z</I>, <I>a</I>), <I>a</I>)
|
|
|
3393 |
</PRE>
|
|
|
3394 |
<I>arg1</I> is evaluated giving <I>off</I>. The next greater or equal
|
|
|
3395 |
<CODE>OFFSET</CODE> at which a value of <CODE>ALIGNMENT</CODE> <I>a</I>
|
|
|
3396 |
can be placed is delivered. That is, there shall not exist an
|
|
|
3397 |
<CODE>OFFSET</CODE> of the same <CODE>SHAPE</CODE> as the result which
|
|
|
3398 |
is greater than or equal to <I>off</I> and less than the result, in
|
|
|
3399 |
the sense of <I>offset_test</I>.
|
|
|
3400 |
<P>
|
|
|
3401 |
<I>off</I> will be a non-negative <CODE>OFFSET</CODE>, that is it
|
|
|
3402 |
will be greater than or equal to a zero <CODE>OFFSET</CODE> of the
|
|
|
3403 |
same <CODE>SHAPE</CODE> in the sense of <I>offset_test</I>.
|
|
|
3404 |
<P>
|
|
|
3405 |
<I>In the simple memory model this operation can be represented by
|
|
|
3406 |
((off + a - 1) / a) * a. In the simple model this is the only operation
|
|
|
3407 |
which is not represented by a simple corresponding integer operation.</I>
|
|
|
3408 |
<P>
|
|
|
3409 |
|
|
|
3410 |
<H3>5.16.88. <A NAME=M170>offset_subtract</A></H3>
|
|
|
3411 |
<B>Encoding number</B>: 87<P>
|
|
|
3412 |
<PRE>
|
|
|
3413 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
3414 |
<I>arg2</I>: EXP OFFSET(<I>x</I>, <I>z</I>)
|
|
|
3415 |
-> EXP OFFSET(<I>z</I>, <I>y</I>)
|
|
|
3416 |
</PRE>
|
|
|
3417 |
The two arguments deliver offsets, <I>p</I> and <I>q</I>. The result
|
|
|
3418 |
is <I>p</I>-<I>q</I>, as an offset.
|
|
|
3419 |
<P>
|
|
|
3420 |
Note that <I>x</I> will include <I>y</I>, <I>x</I> will include <I>z</I>
|
|
|
3421 |
and <I>z</I> will include <I>y</I>, by the constraints on
|
|
|
3422 |
<CODE>OFFSET</CODE>s.
|
|
|
3423 |
<P>
|
|
|
3424 |
<I>offset_subtract and offset_add do not have the conventional relationship
|
|
|
3425 |
because offset_add can lose information, which cannot be regenerated
|
|
|
3426 |
by offset_subtract.</I>
|
|
|
3427 |
<P>
|
|
|
3428 |
|
|
|
3429 |
<H3>5.16.89. <A NAME=M172>offset_test</A></H3>
|
|
|
3430 |
<B>Encoding number</B>: 88<P>
|
|
|
3431 |
<PRE>
|
|
|
3432 |
<I>prob</I>: OPTION(NAT)
|
|
|
3433 |
<I>nt</I>: NTEST
|
|
|
3434 |
<I>dest</I>: LABEL
|
|
|
3435 |
<I>arg1</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
3436 |
<I>arg2</I>: EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
3437 |
-> EXP TOP
|
|
|
3438 |
</PRE>
|
|
|
3439 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce offset
|
|
|
3440 |
values, <I>a</I> and <I>b</I>. These values are compared using <I>nt</I>.
|
|
|
3441 |
<P>
|
|
|
3442 |
If <I>a nt b</I>, this construction yields <CODE>TOP</CODE>. Otherwise
|
|
|
3443 |
control passes to <I>dest</I>.
|
|
|
3444 |
<P>
|
|
|
3445 |
If <I>prob</I> is present, <I>prob</I>/100 gives the probability that
|
|
|
3446 |
control will continue to the next construct (ie. not pass to <I>dest</I>).
|
|
|
3447 |
If <I>prob</I> is absent this probability is unknown.
|
|
|
3448 |
<P>
|
|
|
3449 |
<I>a greater_than_or_equal b</I> is equivalent to
|
|
|
3450 |
<I>offset_max</I>(<I>a</I>, <I>b</I>) = <I>a</I>, and similarly for
|
|
|
3451 |
the other comparisons.
|
|
|
3452 |
<P>
|
|
|
3453 |
<I>In the simple memory model this can be represented by integer_test.</I>
|
|
|
3454 |
<P>
|
|
|
3455 |
|
|
|
3456 |
<H3>5.16.90. <A NAME=M173>offset_zero</A></H3>
|
|
|
3457 |
<B>Encoding number</B>: 89<P>
|
|
|
3458 |
<PRE>
|
|
|
3459 |
<I>a</I>: ALIGNMENT
|
|
|
3460 |
-> EXP OFFSET(<I>a</I>, <I>a</I>)
|
|
|
3461 |
</PRE>
|
|
|
3462 |
A zero offset of <CODE>SHAPE OFFSET</CODE>(<I>a</I>,
|
|
|
3463 |
<I>a</I>).
|
|
|
3464 |
<P>
|
|
|
3465 |
<I>offset_pad</I>(<I>b</I>, <I>offset_zero</I>(<I>a</I>)) is a zero
|
|
|
3466 |
offset of <CODE>SHAPE OFFSET</CODE>(<I>unite_alignments</I>(<I>a</I>,
|
|
|
3467 |
<I>b</I>), <I>b</I>).
|
|
|
3468 |
<P>
|
|
|
3469 |
|
|
|
3470 |
<H3>5.16.91. <A NAME=M174>or</A></H3>
|
|
|
3471 |
<B>Encoding number</B>: 90<P>
|
|
|
3472 |
<PRE>
|
|
|
3473 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3474 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3475 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3476 |
</PRE>
|
|
|
3477 |
The arguments are evaluated producing integer values of the same
|
|
|
3478 |
<CODE>VARIETY</CODE>, <I>v</I>. The result is the bitwise <I>or</I>
|
|
|
3479 |
of these two integers in the representing <CODE>VARIETY</CODE>. The
|
|
|
3480 |
result is delivered as the result of the construct, with the same
|
|
|
3481 |
<CODE>SHAPE</CODE> as the arguments.
|
|
|
3482 |
<P>
|
|
|
3483 |
See <A HREF="spec10.html#51">Representing integers</A>.
|
|
|
3484 |
<P>
|
|
|
3485 |
|
|
|
3486 |
<H3>5.16.92. <A NAME=M175>plus</A></H3>
|
|
|
3487 |
<B>Encoding number</B>: 91<P>
|
|
|
3488 |
<PRE>
|
|
|
3489 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3490 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3491 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3492 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3493 |
</PRE>
|
|
|
3494 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3495 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
3496 |
The sum <I>a</I>+<I>b</I> is delivered as the result of the construct,
|
|
|
3497 |
with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
3498 |
<P>
|
|
|
3499 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
3500 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
3501 |
in the way specified by <I>ov_err</I>.
|
|
|
3502 |
<P>
|
|
|
3503 |
|
|
|
3504 |
<H3>5.16.93. <A NAME=M176>pointer_test</A></H3>
|
|
|
3505 |
<B>Encoding number</B>: 92<P>
|
|
|
3506 |
<PRE>
|
|
|
3507 |
<I>prob</I>: OPTION(NAT)
|
|
|
3508 |
<I>nt</I>: NTEST
|
|
|
3509 |
<I>dest</I>: LABEL
|
|
|
3510 |
<I>arg1</I>: EXP POINTER(<I>x</I>)
|
|
|
3511 |
<I>arg2</I>: EXP POINTER(<I>x</I>)
|
|
|
3512 |
-> EXP TOP
|
|
|
3513 |
</PRE>
|
|
|
3514 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce pointer
|
|
|
3515 |
values, <I>a</I> and <I>b</I>, which will be derived from the same
|
|
|
3516 |
original pointer. These values are compared using <I>nt</I>.
|
|
|
3517 |
<P>
|
|
|
3518 |
If <I>a nt b</I>, this construction yields <CODE>TOP</CODE>. Otherwise
|
|
|
3519 |
control passes to <I>dest</I>.
|
|
|
3520 |
<P>
|
|
|
3521 |
If <I>prob</I> is present, <I>prob</I>/100 gives the probability that
|
|
|
3522 |
control will continue to the next construct (ie. not pass to <I>dest</I>).
|
|
|
3523 |
If <I>prob</I> is absent this probability is unknown.
|
|
|
3524 |
<P>
|
|
|
3525 |
The effect of this construction is the same as:<P>
|
|
|
3526 |
<I>offset_test</I>(<I>prob, nt</I>, <I>dest</I>, <I>subtract_ptrs</I>(<I>arg1
|
|
|
3527 |
</I>,
|
|
|
3528 |
<I>arg2</I>), <I>offset_zero</I>(<I>x</I>))<P>
|
|
|
3529 |
<I>In the simple memory model this construction can be represented
|
|
|
3530 |
by integer_test.</I>
|
|
|
3531 |
<P>
|
|
|
3532 |
|
|
|
3533 |
<H3>5.16.94. <A NAME=M177>power</A></H3>
|
|
|
3534 |
<B>Encoding number</B>: 93<P>
|
|
|
3535 |
<PRE>
|
|
|
3536 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3537 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3538 |
<I>arg2</I>: EXP INTEGER(<I>w</I>)
|
|
|
3539 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3540 |
</PRE>
|
|
|
3541 |
<I>arg2</I> will be non-negative. The result is the result of <I>arg1</I>
|
|
|
3542 |
raised to the power given by <I>arg2</I>.
|
|
|
3543 |
<P>
|
|
|
3544 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
3545 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
3546 |
in the way specified by <I>ov_err</I>.
|
|
|
3547 |
<P>
|
|
|
3548 |
|
|
|
3549 |
<H3>5.16.95. <A NAME=M178>proc_test</A></H3>
|
|
|
3550 |
<B>Encoding number</B>: 94<P>
|
|
|
3551 |
<PRE>
|
|
|
3552 |
<I>prob</I>: OPTION(NAT)
|
|
|
3553 |
<I>nt</I>: NTEST
|
|
|
3554 |
<I>dest</I>: LABEL
|
|
|
3555 |
<I>arg1</I>: EXP PROC
|
|
|
3556 |
<I>arg2</I>: EXP PROC
|
|
|
3557 |
-> EXP TOP
|
|
|
3558 |
</PRE>
|
|
|
3559 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce
|
|
|
3560 |
<CODE>PROC</CODE> values, <I>a</I> and <I>b</I>. These values are
|
|
|
3561 |
compared using <I>nt</I>. The only permitted values of <I>nt</I>
|
|
|
3562 |
are
|
|
|
3563 |
<I>equal</I> and <I>not_equal</I>.
|
|
|
3564 |
<P>
|
|
|
3565 |
If <I>a nt b</I>, this construction yields <CODE>TOP</CODE>. Otherwise
|
|
|
3566 |
control passes to <I>dest</I>.
|
|
|
3567 |
<P>
|
|
|
3568 |
If <I>prob</I> is present, <I>prob</I>/100 gives the probability that
|
|
|
3569 |
control will continue to the next construct (ie. not pass to <I>dest</I>).
|
|
|
3570 |
If <I>prob</I> is absent this probability is unknown.
|
|
|
3571 |
<P>
|
|
|
3572 |
Two <CODE>PROC</CODE>s are equal if they were produced by the same
|
|
|
3573 |
instantiation of <I>make_proc</I> or if they were both made with
|
|
|
3574 |
<I>make_null_proc</I>. Otherwise they are unequal.
|
|
|
3575 |
<P>
|
|
|
3576 |
|
|
|
3577 |
<H3>5.16.96. <A NAME=M179>profile</A></H3>
|
|
|
3578 |
<B>Encoding number</B>: 95<P>
|
|
|
3579 |
<PRE>
|
|
|
3580 |
<I>uses</I>: NAT
|
|
|
3581 |
-> EXP TOP
|
|
|
3582 |
</PRE>
|
|
|
3583 |
The integer <I>uses</I> gives the number of times which this construct
|
|
|
3584 |
is expected to be evaluated.
|
|
|
3585 |
<P>
|
|
|
3586 |
All uses of <I>profile</I> in the same capsule are to the same scale.
|
|
|
3587 |
They will be mutually consistent.
|
|
|
3588 |
<P>
|
|
|
3589 |
|
|
|
3590 |
<H3>5.16.97. <A NAME=M180>real_part</A></H3>
|
|
|
3591 |
<B>Encoding number</B>: 96<P>
|
|
|
3592 |
<PRE>
|
|
|
3593 |
<I>arg1</I>: EXP <I>c</I>
|
|
|
3594 |
-> EXP FLOATING (<I>float_of_complex(c)</I>)
|
|
|
3595 |
</PRE>
|
|
|
3596 |
<I>c</I> will be complex. Delivers the real part of the value produced
|
|
|
3597 |
by <I>arg1</I>.
|
|
|
3598 |
<P>
|
|
|
3599 |
|
|
|
3600 |
<H3>5.16.98. <A NAME=M181>rem0</A></H3>
|
|
|
3601 |
<B>Encoding number</B>: 97<P>
|
|
|
3602 |
<PRE>
|
|
|
3603 |
<I>div_by_0_err</I>: ERROR_TREATMENT
|
|
|
3604 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3605 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3606 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3607 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3608 |
</PRE>
|
|
|
3609 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3610 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
3611 |
The value <I>a</I> M1 <I>b</I> or the value <I>a</I> M2 <I>b</I> is
|
|
|
3612 |
delivered as the result of the construct, with the same <CODE>SHAPE</CODE>
|
|
|
3613 |
as the arguments. Different occurrences of <I>rem0</I> in the same
|
|
|
3614 |
capsule can use M1 or M2 independently.
|
|
|
3615 |
<P>
|
|
|
3616 |
The following equivalence shall hold:
|
|
|
3617 |
<PRE>
|
|
|
3618 |
<I>x = plus(mult(div0(x, y), y), rem0(x, y))</I>
|
|
|
3619 |
</PRE>
|
|
|
3620 |
if all the <CODE>ERROR_TREATMENT</CODE>s are <I>impossible</I>, and
|
|
|
3621 |
<I>x</I> and <I>y</I> have no side effects.
|
|
|
3622 |
<P>
|
|
|
3623 |
If <I>b</I> is zero a div_by_zero error occurs and is handled by
|
|
|
3624 |
<I>div_by_0_err</I>.
|
|
|
3625 |
<P>
|
|
|
3626 |
If <I>b</I> is not zero and <I>div0</I>(<I>a</I>, <I>b</I>) cannot
|
|
|
3627 |
be expressed in the <CODE>VARIETY</CODE> being used to represent <I>v</I>
|
|
|
3628 |
an overflow may occur in which case it is handled by <I>ov_err</I>.
|
|
|
3629 |
<P>
|
|
|
3630 |
Producers may assume that suitable masking and <I>rem0</I> by a power
|
|
|
3631 |
of two yield equally good code.
|
|
|
3632 |
<P>
|
|
|
3633 |
See <A HREF="spec10.html#10">Division and modulus</A> for the definitions
|
|
|
3634 |
of D1, D2, M1 and M2.
|
|
|
3635 |
<P>
|
|
|
3636 |
|
|
|
3637 |
<H3>5.16.99. <A NAME=M182>rem1</A></H3>
|
|
|
3638 |
<B>Encoding number</B>: 98<P>
|
|
|
3639 |
<PRE>
|
|
|
3640 |
<I>div_by_0_err</I>: ERROR_TREATMENT
|
|
|
3641 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3642 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3643 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3644 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3645 |
</PRE>
|
|
|
3646 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3647 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
3648 |
The value <I>a</I> M1 <I>b</I> is delivered as the result of the construct,
|
|
|
3649 |
with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
3650 |
<P>
|
|
|
3651 |
If <I>b</I> is zero a div_by_zero error occurs and is handled by
|
|
|
3652 |
<I>div_by_0_err</I>.
|
|
|
3653 |
<P>
|
|
|
3654 |
If <I>b</I> is not zero and <I>div1</I>(<I>a</I>, <I>b</I>) cannot
|
|
|
3655 |
be expressed in the <CODE>VARIETY</CODE> being used to represent <I>v</I>
|
|
|
3656 |
an overflow may occur, in which case it is handled by <I>ov_err</I>.
|
|
|
3657 |
<P>
|
|
|
3658 |
Producers may assume that suitable masking and <I>rem1</I> by a power
|
|
|
3659 |
of two yield equally good code.
|
|
|
3660 |
<P>
|
|
|
3661 |
See <A HREF="spec10.html#10">Division and modulus</A> for the definitions
|
|
|
3662 |
of D1, D2, M1 and M2.
|
|
|
3663 |
<P>
|
|
|
3664 |
|
|
|
3665 |
<H3>5.16.100. <A NAME=M183>rem2</A></H3>
|
|
|
3666 |
<B>Encoding number</B>: 99<P>
|
|
|
3667 |
<PRE>
|
|
|
3668 |
<I>div_by_0_err</I>: ERROR_TREATMENT
|
|
|
3669 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3670 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3671 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
3672 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3673 |
</PRE>
|
|
|
3674 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3675 |
values, <I>a</I> and <I>b</I>, of the same <CODE>VARIETY</CODE>, <I>v</I>.
|
|
|
3676 |
The value <I>a</I> M2 <I>b</I> is delivered as the result of the construct,
|
|
|
3677 |
with the same <CODE>SHAPE</CODE> as the arguments.
|
|
|
3678 |
<P>
|
|
|
3679 |
If <I>b</I> is zero a div_by_zero error occurs and is handled by
|
|
|
3680 |
<I>div_by_0_err</I>.
|
|
|
3681 |
<P>
|
|
|
3682 |
If <I>b</I> is not zero and <I>div2</I>(<I>a</I>, <I>b</I>) cannot
|
|
|
3683 |
be expressed in the <CODE>VARIETY</CODE> being used to represent <I>v</I>
|
|
|
3684 |
an overflow may occur, in which case it is handled by <I>ov_err</I>.
|
|
|
3685 |
<P>
|
|
|
3686 |
Producers may assume that suitable masking and <I>rem2</I> by a power
|
|
|
3687 |
of two yield equally good code if the lower bound of <I>v</I> is zero.
|
|
|
3688 |
<P>
|
|
|
3689 |
See <A HREF="spec10.html#10">Division and modulus</A> for the definitions
|
|
|
3690 |
of D1, D2, M1 and M2.
|
|
|
3691 |
<P>
|
|
|
3692 |
|
|
|
3693 |
<H3>5.16.101. <A NAME=M184>repeat</A></H3>
|
|
|
3694 |
<!-- BREAK 1 -->
|
|
|
3695 |
<B>Encoding number</B>: 100<P>
|
|
|
3696 |
<PRE>
|
|
|
3697 |
<I>replab_intro</I>: LABEL
|
|
|
3698 |
<I>start</I>: EXP TOP
|
|
|
3699 |
<I>body</I>: EXP <I>y</I>
|
|
|
3700 |
-> EXP <I>y</I>
|
|
|
3701 |
</PRE>
|
|
|
3702 |
<I>start</I> is evaluated. Then <I>body</I> is evaluated.
|
|
|
3703 |
<P>
|
|
|
3704 |
If <I>body</I> produces a result, this is the result of the whole
|
|
|
3705 |
construction. However if <I>goto</I> or any other jump to
|
|
|
3706 |
<I>replab_intro</I> is encountered during the evaluation then the
|
|
|
3707 |
current evaluation stops and <I>body</I> is evaluated again. In the
|
|
|
3708 |
canonical order all evaluated components are completely evaluated
|
|
|
3709 |
before any of the next iteration of <I>body</I>. The lifetime of
|
|
|
3710 |
<I>replab_intro</I> is the evaluation of <I>body</I>.
|
|
|
3711 |
<P>
|
|
|
3712 |
The actual order of evaluation of the constituents shall be indistinguishable
|
|
|
3713 |
in all observable effects (apart from time) from that described above.
|
|
|
3714 |
Note that this specifically includes any defined error handling.
|
|
|
3715 |
<P>
|
|
|
3716 |
|
|
|
3717 |
<H3>5.16.102. <A NAME=M185>return</A></H3>
|
|
|
3718 |
<B>Encoding number</B>: 101<P>
|
|
|
3719 |
<PRE>
|
|
|
3720 |
<I>arg1</I>: EXP <I>x</I>
|
|
|
3721 |
-> EXP BOTTOM
|
|
|
3722 |
</PRE>
|
|
|
3723 |
<I>arg1</I> is evaluated to produce a value, <I>v</I>. The evaluation
|
|
|
3724 |
of the immediately enclosing procedure ceases and <I>v</I> is delivered
|
|
|
3725 |
as the result of the procedure.
|
|
|
3726 |
<P>
|
|
|
3727 |
Since the <I>return</I> construct can never produce a value, the
|
|
|
3728 |
<CODE>SHAPE</CODE> of its result is <CODE>BOTTOM</CODE>.
|
|
|
3729 |
<P>
|
|
|
3730 |
All uses of <I>return</I> in the <I>body</I> of a <I>make_proc</I>
|
|
|
3731 |
or
|
|
|
3732 |
<I>make_general_proc</I> will have <I>arg1</I> with the same
|
|
|
3733 |
<CODE>SHAPE</CODE>.
|
|
|
3734 |
<P>
|
|
|
3735 |
|
|
|
3736 |
<H3>5.16.103. <A NAME=M186>return_to_label</A></H3>
|
|
|
3737 |
<B>Encoding number</B>: 102<P>
|
|
|
3738 |
<PRE>
|
|
|
3739 |
<I>lab_val</I>: EXP POINTER <I>code_alignment</I>
|
|
|
3740 |
-> EXP BOTTOM
|
|
|
3741 |
</PRE>
|
|
|
3742 |
<I>lab_val</I> will be a label value in the calling procedure.
|
|
|
3743 |
<P>
|
|
|
3744 |
The evaluation of the immediately enclosing procedure ceases and control
|
|
|
3745 |
is passed to the calling procedure at the label given by <I>lab_val</I>.
|
|
|
3746 |
<P>
|
|
|
3747 |
|
|
|
3748 |
<H3>5.16.104. <A NAME=M187>round_with_mode</A></H3>
|
|
|
3749 |
<B>Encoding number</B>: 103<P>
|
|
|
3750 |
<PRE>
|
|
|
3751 |
<I>flpt_err</I>: ERROR_TREATMENT
|
|
|
3752 |
<I>mode</I>: ROUNDING_MODE
|
|
|
3753 |
<I>r</I>: VARIETY
|
|
|
3754 |
<I>arg1</I>: EXP FLOATING(<I>f</I>)
|
|
|
3755 |
-> EXP INTEGER(<I>r</I>)
|
|
|
3756 |
</PRE>
|
|
|
3757 |
<I>arg</I> is evaluated to produce a floating point value, <I>v</I>.
|
|
|
3758 |
This is rounded to an integer of <CODE>VARIETY</CODE>, <I>r</I>, using
|
|
|
3759 |
the <CODE>ROUNDING_MODE</CODE>, <I>mode</I>. This is the result of
|
|
|
3760 |
the construction.
|
|
|
3761 |
<P>
|
|
|
3762 |
If <I>f</I> is complex the result is derived from the real part of
|
|
|
3763 |
<I>arg1</I>.
|
|
|
3764 |
<P>
|
|
|
3765 |
If there is a floating point error it is handled by <I>flpt_err</I>.
|
|
|
3766 |
See <A HREF="spec10.html#60">Floating point errors</A>.
|
|
|
3767 |
<P>
|
|
|
3768 |
|
|
|
3769 |
<H3>5.16.105. <A NAME=M188>rotate_left</A></H3>
|
|
|
3770 |
<B>Encoding number</B>: 104<P>
|
|
|
3771 |
<PRE>
|
|
|
3772 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3773 |
<I>arg2</I>: EXP INTEGER(<I>w</I>)
|
|
|
3774 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3775 |
</PRE>
|
|
|
3776 |
The value delivered by <I>arg1</I> is rotated left <I>arg2</I> places.
|
|
|
3777 |
<P>
|
|
|
3778 |
<I>arg2</I> will be non-negative and will be strictly less than the
|
|
|
3779 |
number of bits needed to represent <I>v</I>.
|
|
|
3780 |
<P>
|
|
|
3781 |
The use of this construct assumes knowledge of the representational
|
|
|
3782 |
variety of <I>v</I>.
|
|
|
3783 |
<P>
|
|
|
3784 |
|
|
|
3785 |
<H3>5.16.106. <A NAME=M190>rotate_right</A></H3>
|
|
|
3786 |
<B>Encoding number</B>: 105<P>
|
|
|
3787 |
<PRE>
|
|
|
3788 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3789 |
<I>arg2</I>: EXP INTEGER(<I>w</I>)
|
|
|
3790 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3791 |
</PRE>
|
|
|
3792 |
The value delivered by <I>arg1</I> is rotated right <I>arg2</I> places.
|
|
|
3793 |
<P>
|
|
|
3794 |
<I>arg2</I> will be non-negative and will be strictly less than the
|
|
|
3795 |
number of bits needed to represent <I>v</I>.
|
|
|
3796 |
<P>
|
|
|
3797 |
The use of this construct assumes knowledge of the representational
|
|
|
3798 |
variety of <I>v</I>.
|
|
|
3799 |
<P>
|
|
|
3800 |
|
|
|
3801 |
<H3>5.16.107. <A NAME=M193>sequence</A></H3>
|
|
|
3802 |
<B>Encoding number</B>: 106<P>
|
|
|
3803 |
<PRE>
|
|
|
3804 |
<I>statements</I>: LIST(EXP)
|
|
|
3805 |
<I>result</I>: EXP <I>x</I>
|
|
|
3806 |
-> EXP <I>x</I>
|
|
|
3807 |
</PRE>
|
|
|
3808 |
The statements are evaluated in the same order as the list,
|
|
|
3809 |
<I>statements</I>, and their results are discarded. Then <I>result</I>
|
|
|
3810 |
is evaluated and its result forms the result of the construction.
|
|
|
3811 |
<P>
|
|
|
3812 |
A canonical order is one in which all the components of each statement
|
|
|
3813 |
are completely evaluated before any component of the next statement
|
|
|
3814 |
is started. A similar constraint applies between the last statement
|
|
|
3815 |
and the <I>result</I>. The actual order in which the statements and
|
|
|
3816 |
their components are evaluated shall be indistinguishable in all observable
|
|
|
3817 |
effects (apart from time) from a canonical order.
|
|
|
3818 |
<P>
|
|
|
3819 |
Note that this specifically includes any defined error handling. However,
|
|
|
3820 |
if in any canonical order the effect of the program is undefined,
|
|
|
3821 |
the actual effect of the sequence is undefined.
|
|
|
3822 |
<P>
|
|
|
3823 |
Hence constructions with <I>impossible</I> error handlers may be performed
|
|
|
3824 |
before or after those with specified error handlers, if the resulting
|
|
|
3825 |
order is otherwise acceptable.
|
|
|
3826 |
<P>
|
|
|
3827 |
|
|
|
3828 |
<H3>5.16.108. <A NAME=M194>set_stack_limit</A></H3>
|
|
|
3829 |
<B>Encoding number</B>: 107<P>
|
|
|
3830 |
<PRE>
|
|
|
3831 |
<I>lim</I>: EXP POINTER({<I>locals_alignment, alloca_alignment}</I>)
|
|
|
3832 |
-> EXP TOP
|
|
|
3833 |
</PRE>
|
|
|
3834 |
<I>set_stack_limit</I> sets the limits of remaining free stack space
|
|
|
3835 |
to <I>lim</I>. This include both the frame stack limit and the local_alloc
|
|
|
3836 |
stack. Note that, in implementations where the frame stack and local_alloc
|
|
|
3837 |
stack are distinct, this pointer will have a special representation,
|
|
|
3838 |
appropriate to its frame alignment. Thus the pointer should always
|
|
|
3839 |
be generated using <I>make_stack_limit</I> or its equivalent formation.
|
|
|
3840 |
<P>
|
|
|
3841 |
Any later <I>apply_general_proc</I> with <CODE>PROCPROPS</CODE> including
|
|
|
3842 |
<I>check_stack</I> up to the dynamically next <I>set_stack_limit</I>
|
|
|
3843 |
will check that the frame required for the procedure will be within
|
|
|
3844 |
the frame stack limit. If it is not, normal execution is stopped and
|
|
|
3845 |
a TDF exception with ERROR_CODE <I>stack_overflow</I> is raised.
|
|
|
3846 |
<P>
|
|
|
3847 |
Any later <I>local_alloc_check</I> will check that the locally allocated
|
|
|
3848 |
space required is within the local_alloc stack limit. If it is not,
|
|
|
3849 |
normal execution is stopped and a TDF exception with ERROR_CODE
|
|
|
3850 |
<I>stack_overflow</I> is raised.
|
|
|
3851 |
<P>
|
|
|
3852 |
<P>
|
|
|
3853 |
|
|
|
3854 |
<H3>5.16.109. <A NAME=M196>shape_offset</A></H3>
|
|
|
3855 |
<B>Encoding number</B>: 108<P>
|
|
|
3856 |
<PRE>
|
|
|
3857 |
<I>s</I>: SHAPE
|
|
|
3858 |
-> EXP OFFSET(<I>alignment</I>(<I>s</I>), {})
|
|
|
3859 |
</PRE>
|
|
|
3860 |
This construction delivers the "size" of a value of the
|
|
|
3861 |
given <CODE>SHAPE</CODE>.
|
|
|
3862 |
<P>
|
|
|
3863 |
Suppose that a value of <CODE>SHAPE</CODE>, <I>s</I>, is placed in
|
|
|
3864 |
a space indicated by a <CODE>POINTER</CODE>(<I>x</I>), <I>p</I>, where
|
|
|
3865 |
<I>x</I> includes <I>alignment(s</I>). Suppose that a value of
|
|
|
3866 |
<CODE>SHAPE</CODE>, <I>t</I>, where <I>a</I> is
|
|
|
3867 |
<I>alignment</I>(<I>t</I>) and <I>x</I> includes <I>a</I>, is placed
|
|
|
3868 |
at<P>
|
|
|
3869 |
<I>add_to_ptr</I>(<I>p</I>, <I>offset_pad(a, shape_offset</I>(<I>s</I>)))<P>
|
|
|
3870 |
Then the values shall not overlap. This shall be true for all legal
|
|
|
3871 |
<I>s</I>, <I>x</I> and <I>t</I>.
|
|
|
3872 |
<P>
|
|
|
3873 |
|
|
|
3874 |
<H3>5.16.110. <A NAME=M197>shift_left</A></H3>
|
|
|
3875 |
<B>Encoding number</B>: 109<P>
|
|
|
3876 |
<PRE>
|
|
|
3877 |
<I>ov_err</I>: ERROR_TREATMENT
|
|
|
3878 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3879 |
<I>arg2</I>: EXP INTEGER(<I>w</I>)
|
|
|
3880 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3881 |
</PRE>
|
|
|
3882 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3883 |
values, <I>a</I> and <I>b</I>. The value <I>a</I> shifted left <I>b</I>
|
|
|
3884 |
places is delivered as the result of the construct, with the same
|
|
|
3885 |
<CODE>SHAPE</CODE> as <I>a</I>.
|
|
|
3886 |
<P>
|
|
|
3887 |
<I>b</I> will be non-negative and will be strictly less than the number
|
|
|
3888 |
of bits needed to represent <I>v</I>.
|
|
|
3889 |
<P>
|
|
|
3890 |
If the result cannot be expressed in the <CODE>VARIETY</CODE> being
|
|
|
3891 |
used to represent <I>v</I>, an overflow error is caused and is handled
|
|
|
3892 |
in the way specified by <I>ov_err</I>.
|
|
|
3893 |
<P>
|
|
|
3894 |
Producers may assume that <I>shift_left</I> and multiplication by
|
|
|
3895 |
a power of two yield equally efficient code.
|
|
|
3896 |
<P>
|
|
|
3897 |
|
|
|
3898 |
<H3>5.16.111. <A NAME=M198>shift_right</A></H3>
|
|
|
3899 |
<B>Encoding number</B>: 110<P>
|
|
|
3900 |
<PRE>
|
|
|
3901 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
3902 |
<I>arg2</I>: EXP INTEGER(<I>w</I>)
|
|
|
3903 |
-> EXP INTEGER(<I>v</I>)
|
|
|
3904 |
</PRE>
|
|
|
3905 |
<I>arg1</I> and <I>arg2</I> are evaluated and will produce integer
|
|
|
3906 |
values, <I>a</I> and <I>b</I>. The value <I>a</I> shifted right <I>b</I>
|
|
|
3907 |
places is delivered as the result of the construct, with the same
|
|
|
3908 |
<CODE>SHAPE</CODE> as <I>arg1</I>.
|
|
|
3909 |
<P>
|
|
|
3910 |
<I>b</I> will be non-negative and will be strictly less than the number
|
|
|
3911 |
of bits needed to represent <I>v</I>.
|
|
|
3912 |
<P>
|
|
|
3913 |
If the lower bound of <I>v</I> is negative, the sign will be propagated.
|
|
|
3914 |
<P>
|
|
|
3915 |
|
|
|
3916 |
<H3>5.16.112. <A NAME=M199>subtract_ptrs</A></H3>
|
|
|
3917 |
<B>Encoding number</B>: 111<P>
|
|
|
3918 |
<PRE>
|
|
|
3919 |
<I>arg1</I>: EXP POINTER(<I>y</I>)
|
|
|
3920 |
<I>arg2</I>: EXP POINTER(<I>x</I>)
|
|
|
3921 |
-> EXP OFFSET(<I>x</I>, <I>y</I>)
|
|
|
3922 |
</PRE>
|
|
|
3923 |
<I>arg1</I> and <I>arg2</I> are evaluated to produce pointers <I>p1</I>
|
|
|
3924 |
and <I>p2</I>, which will be derived from the same original pointer.
|
|
|
3925 |
The result, <I>r</I>, is the <CODE>OFFSET</CODE> from <I>p2</I> to
|
|
|
3926 |
<I>p1</I>. Both arguments will be derived from the same original pointer.
|
|
|
3927 |
<P>
|
|
|
3928 |
Note that <I>add_to_ptr</I>(<I>p2</I>, <I>r</I>) = <I>p1</I>.
|
|
|
3929 |
<P>
|
|
|
3930 |
|
|
|
3931 |
<H3>5.16.113. <A NAME=M200>tail_call</A></H3>
|
|
|
3932 |
<B>Encoding number</B>: 112<P>
|
|
|
3933 |
<PRE>
|
|
|
3934 |
<I>prcprops</I>: OPTION(PROCPROPS)
|
|
|
3935 |
<I>p</I>: EXP PROC
|
|
|
3936 |
<I>callee_pars</I>: CALLEES
|
|
|
3937 |
-> EXP BOTTOM
|
|
|
3938 |
</PRE>
|
|
|
3939 |
<I>p</I> is called in the sense of <I>apply_general_proc</I> with
|
|
|
3940 |
the caller parameters of the immediately enclosing proc and
|
|
|
3941 |
<CODE>CALLEES</CODE> given by <I>callee_pars</I> and
|
|
|
3942 |
<CODE>PROCPROPS</CODE> <I>prcprops</I>.
|
|
|
3943 |
<P>
|
|
|
3944 |
The result of the call is delivered as the result of the immediately
|
|
|
3945 |
enclosing proc in the sense of <I>return</I>. The <CODE>SHAPE</CODE>
|
|
|
3946 |
of the result of <I>p</I> will be identical to the <CODE>SHAPE</CODE>
|
|
|
3947 |
specified as the result of immediately enclosing procedure.
|
|
|
3948 |
<P>
|
|
|
3949 |
No pointers to any callee parameters, variables, identifications or
|
|
|
3950 |
local allocations defined in immediately enclosing procedure will
|
|
|
3951 |
be accessed either in the body of <I>p</I> or after the return.
|
|
|
3952 |
<P>
|
|
|
3953 |
The presence or absence of each of the <CODE>PROCPROPS</CODE>
|
|
|
3954 |
<I>check_stack</I> and <I>untidy</I>, in <I>prcprops</I> will be reflected
|
|
|
3955 |
in the <CODE>PROCPROPS</CODE> of the immediately enclosing procedure.
|
|
|
3956 |
<P>
|
|
|
3957 |
|
|
|
3958 |
<H3>5.16.114. <A NAME=M201>untidy_return</A></H3>
|
|
|
3959 |
<B>Encoding number</B>: 113<P>
|
|
|
3960 |
<PRE>
|
|
|
3961 |
<I>arg1</I>: EXP <I>x</I>
|
|
|
3962 |
-> EXP BOTTOM
|
|
|
3963 |
</PRE>
|
|
|
3964 |
<I>arg1</I> is evaluated to produce a value, <I>v</I>. The evaluation
|
|
|
3965 |
of the immediately enclosing procedure ceases and <I>v</I> is delivered
|
|
|
3966 |
as the result of the procedure, in such a manner as that pointers
|
|
|
3967 |
to any callee parameters or local allocations are valid in the calling
|
|
|
3968 |
procedure.
|
|
|
3969 |
<P>
|
|
|
3970 |
<I>untidy_return</I> can only occur in a procedure defined by
|
|
|
3971 |
<I>make_general_proc</I> with <CODE>PROCPROPS</CODE> including
|
|
|
3972 |
<I>untidy</I>.
|
|
|
3973 |
<P>
|
|
|
3974 |
<P>
|
|
|
3975 |
|
|
|
3976 |
<H3>5.16.115. <A NAME=M202>variable</A></H3>
|
|
|
3977 |
<!-- BREAK 3 -->
|
|
|
3978 |
<B>Encoding number</B>: 114<P>
|
|
|
3979 |
<PRE>
|
|
|
3980 |
<I>opt_access</I>: OPTION(ACCESS)
|
|
|
3981 |
<I>name_intro</I>: TAG POINTER(<I>alignment(x</I>))
|
|
|
3982 |
<I>init</I>: EXP <I>x</I>
|
|
|
3983 |
<I>body</I>: EXP <I>y</I>
|
|
|
3984 |
-> EXP <I>y</I>
|
|
|
3985 |
</PRE>
|
|
|
3986 |
<I>init</I> is evaluated to produce a value, <I>v</I>. Space is allocated
|
|
|
3987 |
to hold a value of <CODE>SHAPE</CODE> <I>x</I>
|
|
|
3988 |
and this is initialised with <I>v</I>. Then <I>body</I> is evaluated.
|
|
|
3989 |
During this evaluation, an original <CODE>POINTER</CODE> pointing
|
|
|
3990 |
to the allocated space is bound to <I>name_intro</I>. This means that
|
|
|
3991 |
inside <I>body</I> an evaluation of <I>obtain_tag</I>(<I>name_intro</I>)
|
|
|
3992 |
will produce a <CODE>POINTER</CODE> to this space. The lifetime of
|
|
|
3993 |
<I>name_intro</I> is the evaluation of <I>body</I>.
|
|
|
3994 |
<P>
|
|
|
3995 |
The value delivered by <I>variable</I> is that produced by <I>body</I>.
|
|
|
3996 |
<P>
|
|
|
3997 |
If <I>opt_access</I> contains <I>visible</I>, it means that the contents
|
|
|
3998 |
of the space may be altered while the procedure containing this declaration
|
|
|
3999 |
is not the current procedure. Hence if there are any copies of this
|
|
|
4000 |
value they will need to be refreshed from the variable when the procedure
|
|
|
4001 |
is returned to. The easiest implementation when <I>opt_access</I>
|
|
|
4002 |
is <I>visible</I> may be to keep the value in memory, but this is
|
|
|
4003 |
not a necessary requirement.
|
|
|
4004 |
<P>
|
|
|
4005 |
The <CODE>TAG</CODE> given for <I>name_intro</I> will not be reused
|
|
|
4006 |
within the current <CODE>UNIT</CODE>. No rules for the hiding of one
|
|
|
4007 |
<CODE>TAG</CODE> by another are given: this will not happen.
|
|
|
4008 |
<P>
|
|
|
4009 |
The order in which the constituents of <I>init</I> and <I>body</I>
|
|
|
4010 |
are evaluated shall be indistinguishable in all observable effects
|
|
|
4011 |
(apart from time) from completely evaluating <I>init</I> before starting
|
|
|
4012 |
<I>body</I>. See the note about order in
|
|
|
4013 |
<A HREF="#M193">sequence</A>.
|
|
|
4014 |
<P>
|
|
|
4015 |
When compiling languages which permit uninitialised variable declarations,
|
|
|
4016 |
<I>make_value</I> may be used to provide an initialisation.
|
|
|
4017 |
<P>
|
|
|
4018 |
|
|
|
4019 |
<H3>5.16.116. <A NAME=M204>xor</A></H3>
|
|
|
4020 |
<B>Encoding number</B>: 115<P>
|
|
|
4021 |
<PRE>
|
|
|
4022 |
<I>arg1</I>: EXP INTEGER(<I>v</I>)
|
|
|
4023 |
<I>arg2</I>: EXP INTEGER(<I>v</I>)
|
|
|
4024 |
-> EXP INTEGER(<I>v</I>)
|
|
|
4025 |
</PRE>
|
|
|
4026 |
The arguments are evaluated producing integer values of the same
|
|
|
4027 |
<CODE>VARIETY</CODE>, <I>v</I>. The result is the bitwise <I>xor</I>
|
|
|
4028 |
of these two integers in the representing <CODE>VARIETY</CODE>. The
|
|
|
4029 |
result is delivered as the result of the construct, with the same
|
|
|
4030 |
<CODE>SHAPE</CODE> as the arguments.
|
|
|
4031 |
<P>
|
|
|
4032 |
See <A HREF="spec10.html#51">Representing integers</A>.
|
|
|
4033 |
<P>
|
|
|
4034 |
|
|
|
4035 |
<HR>
|
|
|
4036 |
<H2>5.17. <A NAME=M205>EXTERNAL</A></H2>
|
|
|
4037 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
4038 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4039 |
An <CODE>EXTERNAL</CODE> defines the classes of external name available
|
|
|
4040 |
for connecting the internal names inside a <CODE>CAPSULE</CODE> to
|
|
|
4041 |
the world outside the <CODE>CAPSULE</CODE>.
|
|
|
4042 |
<P>
|
|
|
4043 |
|
|
|
4044 |
<H3>5.17.1. <A NAME=M206>string_extern</A></H3>
|
|
|
4045 |
<!-- ALIGN 0 -->
|
|
|
4046 |
<B>Encoding number</B>: 1<P>
|
|
|
4047 |
<PRE>
|
|
|
4048 |
<I>s</I>: BYTE_ALIGN TDFIDENT(<I>n</I>)
|
|
|
4049 |
-> EXTERNAL
|
|
|
4050 |
</PRE>
|
|
|
4051 |
<I>string_extern</I> produces an <CODE>EXTERNAL</CODE> identified
|
|
|
4052 |
by the <CODE>TDFIDENT</CODE> <I>s</I>.
|
|
|
4053 |
<P>
|
|
|
4054 |
|
|
|
4055 |
<H3>5.17.2. <A NAME=M207>unique_extern</A></H3>
|
|
|
4056 |
<!-- ALIGN 0 -->
|
|
|
4057 |
<B>Encoding number</B>: 2<P>
|
|
|
4058 |
<PRE>
|
|
|
4059 |
<I>u</I>: BYTE_ALIGN UNIQUE
|
|
|
4060 |
-> EXTERNAL
|
|
|
4061 |
</PRE>
|
|
|
4062 |
<I>unique_extern</I> produces an <CODE>EXTERNAL</CODE> identified
|
|
|
4063 |
by the <CODE>UNIQUE</CODE> <I>u</I>.
|
|
|
4064 |
<P>
|
|
|
4065 |
|
|
|
4066 |
<H3>5.17.3. <A NAME=M208>chain_extern</A></H3>
|
|
|
4067 |
<!-- ALIGN 0 -->
|
|
|
4068 |
<B>Encoding number</B>: 3<P>
|
|
|
4069 |
<PRE>
|
|
|
4070 |
<I>s</I>: BYTE_ALIGN TDFIDENT
|
|
|
4071 |
<I>prev</I>: TDFINT
|
|
|
4072 |
-> EXTERNAL
|
|
|
4073 |
</PRE>
|
|
|
4074 |
This construct is redundant and should not be used.
|
|
|
4075 |
<P>
|
|
|
4076 |
|
|
|
4077 |
<HR>
|
|
|
4078 |
<H2>5.18. <A NAME=M209>EXTERN_LINK</A></H2>
|
|
|
4079 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
4080 |
<B>Is coding extendable</B>: no<P>
|
|
|
4081 |
An auxiliary <CODE>SORT</CODE> providing a list of <CODE>LINKEXTERN</CODE>.
|
|
|
4082 |
<P>
|
|
|
4083 |
|
|
|
4084 |
<H3>5.18.1. <A NAME=M210>make_extern_link</A></H3>
|
|
|
4085 |
<B>Encoding number</B>: 0<P>
|
|
|
4086 |
<PRE>
|
|
|
4087 |
<I>el</I>: SLIST(LINKEXTERN)
|
|
|
4088 |
-> EXTERN_LINK
|
|
|
4089 |
</PRE>
|
|
|
4090 |
<I>make_capsule</I> requires a <CODE>SLIST</CODE>(<CODE>EXTERN_LINK</CODE>)
|
|
|
4091 |
to express the links between the linkable entities and the named (by
|
|
|
4092 |
<CODE>EXTERNAL</CODE>s) values outside the <CODE>CAPSULE</CODE>.
|
|
|
4093 |
<P>
|
|
|
4094 |
|
|
|
4095 |
<HR>
|
|
|
4096 |
<H2>5.19. <A NAME=M303>FLOATING_VARIETY</A></H2>
|
|
|
4097 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
4098 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4099 |
These describe kinds of floating point number.
|
|
|
4100 |
<P>
|
|
|
4101 |
|
|
|
4102 |
<H3>5.19.1. <A NAME=M212>flvar_apply_token</A></H3>
|
|
|
4103 |
<B>Encoding number</B>: 1<P>
|
|
|
4104 |
<PRE>
|
|
|
4105 |
<I>token_value</I>: TOKEN
|
|
|
4106 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4107 |
-> FLOATING_VARIETY
|
|
|
4108 |
</PRE>
|
|
|
4109 |
The token is applied to the arguments to give a
|
|
|
4110 |
<CODE>FLOATING_VARIETY</CODE><P> If there is a definition for
|
|
|
4111 |
<I>token_value</I> in the <CODE>CAPSULE</CODE> then <I>token_args</I>
|
|
|
4112 |
is a <CODE>BITSTREAM</CODE> encoding of the <CODE>SORT</CODE>s of
|
|
|
4113 |
its parameters, in the order specified.
|
|
|
4114 |
<P>
|
|
|
4115 |
|
|
|
4116 |
<H3>5.19.2. <A NAME=M213>flvar_cond</A></H3>
|
|
|
4117 |
<B>Encoding number</B>: 2<P>
|
|
|
4118 |
<PRE>
|
|
|
4119 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
4120 |
<I>e1</I>: BITSTREAM FLOATING_VARIETY
|
|
|
4121 |
<I>e2</I>: BITSTREAM FLOATING_VARIETY
|
|
|
4122 |
-> FLOATING_VARIETY
|
|
|
4123 |
</PRE>
|
|
|
4124 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
4125 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
4126 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
4127 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
4128 |
and <I>e1</I> is ignored and never processed.
|
|
|
4129 |
<P>
|
|
|
4130 |
|
|
|
4131 |
<H3>5.19.3. <A NAME=M214>flvar_parms</A></H3>
|
|
|
4132 |
<B>Encoding number</B>: 3<P>
|
|
|
4133 |
<PRE>
|
|
|
4134 |
<I>base</I>: NAT
|
|
|
4135 |
<I>mantissa_digs</I>: NAT
|
|
|
4136 |
<I>min_exponent</I>: NAT
|
|
|
4137 |
<I>max_exponent</I>: NAT
|
|
|
4138 |
-> FLOATING_VARIETY
|
|
|
4139 |
</PRE>
|
|
|
4140 |
<I>base</I> is the base with respect to which the remaining numbers
|
|
|
4141 |
refer. <I>base</I> will be a power of 2.
|
|
|
4142 |
<P>
|
|
|
4143 |
<I>mantissa_digs</I> is the required number of <I>base</I> digits,
|
|
|
4144 |
<I>q</I>, such that any number with <I>q</I> digits can be rounded
|
|
|
4145 |
to a floating point number of the variety and back again without any
|
|
|
4146 |
change to the <I>q</I> digits.
|
|
|
4147 |
<P>
|
|
|
4148 |
<I>min_exponent</I> is the negative of the required minimum integer
|
|
|
4149 |
such that <I>base</I> raised to that power can be represented as a
|
|
|
4150 |
non-zero floating point number in the <CODE>FLOATING_VARIETY</CODE>.
|
|
|
4151 |
<P>
|
|
|
4152 |
<I>max_exponent</I> is the required maximum integer such that
|
|
|
4153 |
<I>base</I> raised to that power can be represented in the
|
|
|
4154 |
<CODE>FLOATING_VARIETY</CODE>.
|
|
|
4155 |
<P>
|
|
|
4156 |
A TDF translator is required to make available a representing
|
|
|
4157 |
<CODE>FLOATING_VARIETY</CODE> such that, if only values within the
|
|
|
4158 |
given requirements are produced, no overflow error will occur. Where
|
|
|
4159 |
several such representative <CODE>FLOATING_VARIETY</CODE>s exist,
|
|
|
4160 |
the translator will choose one to minimise space requirements or maximise
|
|
|
4161 |
the speed of operations.
|
|
|
4162 |
<P>
|
|
|
4163 |
All numbers of the form xb1 M*<I>base N+1-q</I> are required to be
|
|
|
4164 |
represented exactly where M and N are integers such that<BR>
|
|
|
4165 |
<I>base</I><I>q-1</I> M < <I>base</I><I>q</I><BR>
|
|
|
4166 |
-<I>min_exponent</I> N <I>max_exponent</I><P>
|
|
|
4167 |
Zero will also be represented exactly in any <CODE>FLOATING_VARIETY</CODE>.
|
|
|
4168 |
<P>
|
|
|
4169 |
|
|
|
4170 |
<H3>5.19.4. <A NAME=M215>complex_parms</A></H3>
|
|
|
4171 |
<B>Encoding number</B>: 4<P>
|
|
|
4172 |
<PRE>
|
|
|
4173 |
<I>base</I>: NAT
|
|
|
4174 |
<I>mantissa_digs</I>: NAT
|
|
|
4175 |
<I>min_exponent</I>: NAT
|
|
|
4176 |
<I>max_exponent</I>: NAT
|
|
|
4177 |
-> FLOATING_VARIETY
|
|
|
4178 |
</PRE>
|
|
|
4179 |
A <CODE>FLOATING_VARIETY</CODE> described by <I>complex_parms</I>
|
|
|
4180 |
holds a complex number which is likely to be represented by its real
|
|
|
4181 |
and imaginary parts, each of which is as if defined by <I>flvar_parms</I>
|
|
|
4182 |
with the same arguments.
|
|
|
4183 |
<P>
|
|
|
4184 |
|
|
|
4185 |
<H3>5.19.5. <A NAME=M216>float_of_complex</A></H3>
|
|
|
4186 |
<B>Encoding number</B>: 5<P>
|
|
|
4187 |
<PRE>
|
|
|
4188 |
<I>csh</I>: SHAPE
|
|
|
4189 |
-> FLOATING_VARIETY
|
|
|
4190 |
</PRE>
|
|
|
4191 |
<I>csh</I> will be a complex <CODE>SHAPE</CODE>.
|
|
|
4192 |
<P>
|
|
|
4193 |
Delivers the <CODE>FLOATING_VARIETY</CODE> required for the real (or
|
|
|
4194 |
imaginary) part of a complex <CODE>SHAPE</CODE> <I>csh</I>.
|
|
|
4195 |
<P>
|
|
|
4196 |
|
|
|
4197 |
<H3>5.19.6. <A NAME=M217>complex_of_float</A></H3>
|
|
|
4198 |
<B>Encoding number</B>: 6<P>
|
|
|
4199 |
<PRE>
|
|
|
4200 |
<I>fsh</I>: SHAPE
|
|
|
4201 |
-> FLOATING_VARIETY
|
|
|
4202 |
</PRE>
|
|
|
4203 |
<I>fsh</I> will be a floating <CODE>SHAPE</CODE>.
|
|
|
4204 |
<P>
|
|
|
4205 |
Delivers <CODE>FLOATING_VARIETY</CODE> required for a complex number
|
|
|
4206 |
whose real (and imaginary) parts have <CODE>SHAPE</CODE> <I>fsh</I>.
|
|
|
4207 |
<P>
|
|
|
4208 |
<P>
|
|
|
4209 |
|
|
|
4210 |
<HR>
|
|
|
4211 |
<H2>5.20. <A NAME=M218>GROUP</A></H2>
|
|
|
4212 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
4213 |
<B>Is coding extendable</B>: no<P>
|
|
|
4214 |
A <CODE>GROUP</CODE> is a list of <CODE>UNIT</CODE>s with the same
|
|
|
4215 |
unit identification.
|
|
|
4216 |
<P>
|
|
|
4217 |
|
|
|
4218 |
<H3>5.20.1. <A NAME=M219>make_group</A></H3>
|
|
|
4219 |
<B>Encoding number</B>: 0<P>
|
|
|
4220 |
<PRE>
|
|
|
4221 |
<I>us</I>: SLIST(UNIT)
|
|
|
4222 |
-> GROUP
|
|
|
4223 |
</PRE>
|
|
|
4224 |
<I>make_capsule</I> contains a list of <CODE>GROUPS</CODE>. Each member
|
|
|
4225 |
of this list has a different unit identification deduced from the
|
|
|
4226 |
<I>prop_name</I> argument of <I>make_capsule</I>.
|
|
|
4227 |
<P>
|
|
|
4228 |
|
|
|
4229 |
<HR>
|
|
|
4230 |
<H2>5.21. <A NAME=M305>LABEL</A></H2>
|
|
|
4231 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
4232 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4233 |
A <CODE>LABEL</CODE> marks an <CODE>EXP</CODE> in certain constructions,
|
|
|
4234 |
and is used in jump-like constructions to change the control to the
|
|
|
4235 |
labelled construction.
|
|
|
4236 |
<P>
|
|
|
4237 |
|
|
|
4238 |
<H3>5.21.1. <A NAME=M221>label_apply_token</A></H3>
|
|
|
4239 |
<B>Encoding number</B>: 2<P>
|
|
|
4240 |
<PRE>
|
|
|
4241 |
<I>token_value</I>: TOKEN
|
|
|
4242 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4243 |
-> LABEL <I>x</I>
|
|
|
4244 |
</PRE>
|
|
|
4245 |
The token is applied to the arguments to give a <CODE>LABEL</CODE>.
|
|
|
4246 |
<P>
|
|
|
4247 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
4248 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
4249 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
4250 |
<P>
|
|
|
4251 |
|
|
|
4252 |
<H3>5.21.2. <A NAME=M222>make_label</A></H3>
|
|
|
4253 |
<B>Encoding number</B>: 1<P>
|
|
|
4254 |
<PRE>
|
|
|
4255 |
<I>labelno</I>: TDFINT
|
|
|
4256 |
-> LABEL
|
|
|
4257 |
</PRE>
|
|
|
4258 |
Labels are represented in TDF by integers, but they are not linkable.
|
|
|
4259 |
Hence the definition and all uses of a <CODE>LABEL</CODE> occur in
|
|
|
4260 |
the same <CODE>UNIT</CODE>.
|
|
|
4261 |
<P>
|
|
|
4262 |
|
|
|
4263 |
<HR>
|
|
|
4264 |
<H2>5.22. <A NAME=M223>LINK</A></H2>
|
|
|
4265 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
4266 |
<B>Is coding extendable</B>: no<P>
|
|
|
4267 |
A <CODE>LINK</CODE> expresses the connection between two variables
|
|
|
4268 |
of the same <CODE>SORT</CODE>.
|
|
|
4269 |
<P>
|
|
|
4270 |
|
|
|
4271 |
<H3>5.22.1. <A NAME=M224>make_link</A></H3>
|
|
|
4272 |
<B>Encoding number</B>: 0<P>
|
|
|
4273 |
<PRE>
|
|
|
4274 |
<I>unit_name</I>: TDFINT
|
|
|
4275 |
<I>capsule_name</I>: TDFINT
|
|
|
4276 |
-> LINK
|
|
|
4277 |
</PRE>
|
|
|
4278 |
A <CODE>LINK</CODE> defines a linkable entity declared inside a
|
|
|
4279 |
<CODE>UNIT</CODE> as <I>unit_name</I> to correspond to a
|
|
|
4280 |
<CODE>CAPSULE</CODE> linkable entity having the same linkable entity
|
|
|
4281 |
identification. The <CODE>CAPSULE</CODE> linkable entity is
|
|
|
4282 |
<I>capsule_name</I>.
|
|
|
4283 |
<P>
|
|
|
4284 |
A <CODE>LINK</CODE> is normally constructed by the TDF builder in
|
|
|
4285 |
the course of resolving sharing and name clashes when constructing
|
|
|
4286 |
a composite <CODE>CAPSULE</CODE>.
|
|
|
4287 |
<P>
|
|
|
4288 |
|
|
|
4289 |
<HR>
|
|
|
4290 |
<H2>5.23. <A NAME=M225>LINKEXTERN</A></H2>
|
|
|
4291 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
4292 |
<B>Is coding extendable</B>: no<P>
|
|
|
4293 |
A value of <CODE>SORT LINKEXTERN</CODE> expresses the connection between
|
|
|
4294 |
the name by which an object is known inside a <CODE>CAPSULE</CODE>
|
|
|
4295 |
and a name by which it is known outside.
|
|
|
4296 |
<P>
|
|
|
4297 |
|
|
|
4298 |
<H3>5.23.1. <A NAME=M226>make_linkextern</A></H3>
|
|
|
4299 |
<B>Encoding number</B>: 0<P>
|
|
|
4300 |
<PRE>
|
|
|
4301 |
<I>internal</I>: TDFINT
|
|
|
4302 |
<I>ext</I>: EXTERNAL
|
|
|
4303 |
-> LINKEXTERN
|
|
|
4304 |
</PRE>
|
|
|
4305 |
<I>make_linkextern</I> produces a <CODE>LINKEXTERN</CODE> connecting
|
|
|
4306 |
an object identified within a <CODE>CAPSULE</CODE> by a <CODE>TAG</CODE>,
|
|
|
4307 |
<CODE>TOKEN</CODE>, <CODE>AL_TAG</CODE> or any linkable entity constructed
|
|
|
4308 |
from <I>internal</I>, with an <CODE>EXTERNAL</CODE>, <I>ext</I>. The
|
|
|
4309 |
<CODE>EXTERNAL</CODE> is an identifier which linkers and similar programs
|
|
|
4310 |
can use.
|
|
|
4311 |
<P>
|
|
|
4312 |
|
|
|
4313 |
<HR>
|
|
|
4314 |
<H2>5.24. <A NAME=M227>LINKS</A></H2>
|
|
|
4315 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
4316 |
<B>Is coding extendable</B>: no<P>
|
|
|
4317 |
|
|
|
4318 |
<H3>5.24.1. <A NAME=M228>make_links</A></H3>
|
|
|
4319 |
<B>Encoding number</B>: 0<P>
|
|
|
4320 |
<PRE>
|
|
|
4321 |
<I>ls</I>: SLIST(LINK)
|
|
|
4322 |
-> LINKS
|
|
|
4323 |
</PRE>
|
|
|
4324 |
<I>make_unit</I> uses a <CODE>SLIST</CODE>(<CODE>LINKS</CODE>) to
|
|
|
4325 |
define which linkable entities within a <CODE>UNIT</CODE> correspond
|
|
|
4326 |
to the <CODE>CAPSULE</CODE> linkable entities. Each <CODE>LINK</CODE>
|
|
|
4327 |
in a <CODE>LINKS</CODE> has the same linkable entity identification.
|
|
|
4328 |
<P>
|
|
|
4329 |
|
|
|
4330 |
<HR>
|
|
|
4331 |
<H2>5.25. <A NAME=M306>NAT</A></H2>
|
|
|
4332 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
4333 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4334 |
These are non-negative integers of unlimited size.
|
|
|
4335 |
<P>
|
|
|
4336 |
|
|
|
4337 |
<H3>5.25.1. <A NAME=M230>nat_apply_token</A></H3>
|
|
|
4338 |
<B>Encoding number</B>: 1<P>
|
|
|
4339 |
<PRE>
|
|
|
4340 |
<I>token_value</I>: TOKEN
|
|
|
4341 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4342 |
-> NAT
|
|
|
4343 |
</PRE>
|
|
|
4344 |
The token is applied to the arguments to give a <CODE>NAT</CODE>.
|
|
|
4345 |
<P>
|
|
|
4346 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
4347 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
4348 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
4349 |
<P>
|
|
|
4350 |
|
|
|
4351 |
<H3>5.25.2. <A NAME=M231>nat_cond</A></H3>
|
|
|
4352 |
<B>Encoding number</B>: 2<P>
|
|
|
4353 |
<PRE>
|
|
|
4354 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
4355 |
<I>e1</I>: BITSTREAM NAT
|
|
|
4356 |
<I>e2</I>: BITSTREAM NAT
|
|
|
4357 |
-> NAT
|
|
|
4358 |
</PRE>
|
|
|
4359 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
4360 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
4361 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
4362 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
4363 |
and <I>e1</I> is ignored and never processed.
|
|
|
4364 |
<P>
|
|
|
4365 |
|
|
|
4366 |
<H3>5.25.3. <A NAME=M232>computed_nat</A></H3>
|
|
|
4367 |
<B>Encoding number</B>: 3<P>
|
|
|
4368 |
<PRE>
|
|
|
4369 |
<I>arg</I>: EXP INTEGER(<I>v</I>)
|
|
|
4370 |
-> NAT
|
|
|
4371 |
</PRE>
|
|
|
4372 |
<I>arg</I> will be an install-time non-negative constant. The result
|
|
|
4373 |
is that constant.
|
|
|
4374 |
<P>
|
|
|
4375 |
|
|
|
4376 |
<H3>5.25.4. <A NAME=M233>error_val</A></H3>
|
|
|
4377 |
<B>Encoding number</B>: 4<P>
|
|
|
4378 |
<PRE>
|
|
|
4379 |
<I>err</I>: ERROR_CODE
|
|
|
4380 |
-> NAT
|
|
|
4381 |
</PRE>
|
|
|
4382 |
Gives the <CODE>NAT</CODE> corresponding to the <CODE>ERROR_CODE</CODE>
|
|
|
4383 |
<I>err</I>. Each distinct <CODE>ERROR_CODE</CODE> will give a different
|
|
|
4384 |
<CODE>NAT</CODE>.
|
|
|
4385 |
<P>
|
|
|
4386 |
|
|
|
4387 |
<H3>5.25.5. <A NAME=M234>make_nat</A></H3>
|
|
|
4388 |
<B>Encoding number</B>: 5<P>
|
|
|
4389 |
<PRE>
|
|
|
4390 |
<I>n</I>: TDFINT
|
|
|
4391 |
-> NAT
|
|
|
4392 |
</PRE>
|
|
|
4393 |
<I>n</I> is a non-negative integer of unbounded magnitude.
|
|
|
4394 |
<P>
|
|
|
4395 |
|
|
|
4396 |
<HR>
|
|
|
4397 |
<H2>5.26. <A NAME=M307>NTEST</A></H2>
|
|
|
4398 |
<B>Number of encoding bits</B>: 4<BR>
|
|
|
4399 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4400 |
These describe the comparisons which are possible in the various
|
|
|
4401 |
<I>test</I> constructions. Note that <I>greater_than</I> is not necessarily
|
|
|
4402 |
the same as <I>not_less_than_or_equal</I>, since the result need not
|
|
|
4403 |
be defined (e.g. in IEEE floating point).
|
|
|
4404 |
<P>
|
|
|
4405 |
|
|
|
4406 |
<H3>5.26.1. <A NAME=M236>ntest_apply_token</A></H3>
|
|
|
4407 |
<B>Encoding number</B>: 1<P>
|
|
|
4408 |
<PRE>
|
|
|
4409 |
<I>token_value</I>: TOKEN
|
|
|
4410 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4411 |
-> NTEST
|
|
|
4412 |
</PRE>
|
|
|
4413 |
The token is applied to the arguments to give a <CODE>NTEST</CODE>.
|
|
|
4414 |
<P>
|
|
|
4415 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
4416 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
4417 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
4418 |
<P>
|
|
|
4419 |
|
|
|
4420 |
<H3>5.26.2. <A NAME=M237>ntest_cond</A></H3>
|
|
|
4421 |
<B>Encoding number</B>: 2<P>
|
|
|
4422 |
<PRE>
|
|
|
4423 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
4424 |
<I>e1</I>: BITSTREAM NTEST
|
|
|
4425 |
<I>e2</I>: BITSTREAM NTEST
|
|
|
4426 |
-> NTEST
|
|
|
4427 |
</PRE>
|
|
|
4428 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
4429 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
4430 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
4431 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
4432 |
and <I>e1</I> is ignored and never processed.
|
|
|
4433 |
<P>
|
|
|
4434 |
|
|
|
4435 |
<H3>5.26.3. <A NAME=M238>equal</A></H3>
|
|
|
4436 |
<B>Encoding number</B>: 3<P>
|
|
|
4437 |
<PRE>
|
|
|
4438 |
-> NTEST
|
|
|
4439 |
</PRE>
|
|
|
4440 |
Signifies "equal" test.
|
|
|
4441 |
<P>
|
|
|
4442 |
|
|
|
4443 |
<H3>5.26.4. <A NAME=M239>greater_than</A></H3>
|
|
|
4444 |
<B>Encoding number</B>: 4<P>
|
|
|
4445 |
<PRE>
|
|
|
4446 |
-> NTEST
|
|
|
4447 |
</PRE>
|
|
|
4448 |
Signifies "greater than" test.
|
|
|
4449 |
<P>
|
|
|
4450 |
|
|
|
4451 |
<H3>5.26.5. <A NAME=M240>greater_than_or_equal</A></H3>
|
|
|
4452 |
<B>Encoding number</B>: 5<P>
|
|
|
4453 |
<PRE>
|
|
|
4454 |
-> NTEST
|
|
|
4455 |
</PRE>
|
|
|
4456 |
Signifies "greater than or equal" test.
|
|
|
4457 |
<P>
|
|
|
4458 |
|
|
|
4459 |
<H3>5.26.6. <A NAME=M241>less_than</A></H3>
|
|
|
4460 |
<B>Encoding number</B>: 6<P>
|
|
|
4461 |
<PRE>
|
|
|
4462 |
-> NTEST
|
|
|
4463 |
</PRE>
|
|
|
4464 |
Signifies "less than" test.
|
|
|
4465 |
<P>
|
|
|
4466 |
|
|
|
4467 |
<H3>5.26.7. <A NAME=M242>less_than_or_equal</A></H3>
|
|
|
4468 |
<B>Encoding number</B>: 7<P>
|
|
|
4469 |
<PRE>
|
|
|
4470 |
-> NTEST
|
|
|
4471 |
</PRE>
|
|
|
4472 |
Signifies "less than or equal" test.
|
|
|
4473 |
<P>
|
|
|
4474 |
|
|
|
4475 |
<H3>5.26.8. <A NAME=M243>not_equal</A></H3>
|
|
|
4476 |
<B>Encoding number</B>: 8<P>
|
|
|
4477 |
<PRE>
|
|
|
4478 |
-> NTEST
|
|
|
4479 |
</PRE>
|
|
|
4480 |
Signifies "not equal" test.
|
|
|
4481 |
<P>
|
|
|
4482 |
|
|
|
4483 |
<H3>5.26.9. <A NAME=M244>not_greater_than</A></H3>
|
|
|
4484 |
<B>Encoding number</B>: 9<P>
|
|
|
4485 |
<PRE>
|
|
|
4486 |
-> NTEST
|
|
|
4487 |
</PRE>
|
|
|
4488 |
Signifies "not greater than" test.
|
|
|
4489 |
<P>
|
|
|
4490 |
|
|
|
4491 |
<H3>5.26.10. <A NAME=M245>not_greater_than_or_equal</A></H3>
|
|
|
4492 |
<B>Encoding number</B>: 10<P>
|
|
|
4493 |
<PRE>
|
|
|
4494 |
-> NTEST
|
|
|
4495 |
</PRE>
|
|
|
4496 |
Signifies "not (greater than or equal)" test.
|
|
|
4497 |
<P>
|
|
|
4498 |
|
|
|
4499 |
<H3>5.26.11. <A NAME=M246>not_less_than</A></H3>
|
|
|
4500 |
<B>Encoding number</B>: 11<P>
|
|
|
4501 |
<PRE>
|
|
|
4502 |
-> NTEST
|
|
|
4503 |
</PRE>
|
|
|
4504 |
Signifies "not less than" test.
|
|
|
4505 |
<P>
|
|
|
4506 |
|
|
|
4507 |
<H3>5.26.12. <A NAME=M247>not_less_than_or_equal</A></H3>
|
|
|
4508 |
<B>Encoding number</B>: 12<P>
|
|
|
4509 |
<PRE>
|
|
|
4510 |
-> NTEST
|
|
|
4511 |
</PRE>
|
|
|
4512 |
Signifies "not (less than or equal)" test.
|
|
|
4513 |
<P>
|
|
|
4514 |
|
|
|
4515 |
<H3>5.26.13. <A NAME=M248>less_than_or_greater_than</A></H3>
|
|
|
4516 |
<B>Encoding number</B>: 13<P>
|
|
|
4517 |
<PRE>
|
|
|
4518 |
-> NTEST
|
|
|
4519 |
</PRE>
|
|
|
4520 |
Signifies "less than or greater than" test.
|
|
|
4521 |
<P>
|
|
|
4522 |
|
|
|
4523 |
<H3>5.26.14. <A NAME=M249>not_less_than_and_not_greater_than</A></H3>
|
|
|
4524 |
<B>Encoding number</B>: 14<P>
|
|
|
4525 |
<PRE>
|
|
|
4526 |
-> NTEST
|
|
|
4527 |
</PRE>
|
|
|
4528 |
Signifies "not less than and not greater than" test.
|
|
|
4529 |
<P>
|
|
|
4530 |
|
|
|
4531 |
<H3>5.26.15. <A NAME=M250>comparable</A></H3>
|
|
|
4532 |
<B>Encoding number</B>: 15<P>
|
|
|
4533 |
<PRE>
|
|
|
4534 |
-> NTEST
|
|
|
4535 |
</PRE>
|
|
|
4536 |
Signifies "comparable" test.
|
|
|
4537 |
<P>
|
|
|
4538 |
With all operands <CODE>SHAPE</CODE>s except <CODE>FLOATING</CODE>,
|
|
|
4539 |
this comparison is always true.
|
|
|
4540 |
<P>
|
|
|
4541 |
|
|
|
4542 |
<H3>5.26.16. <A NAME=M251>not_comparable</A></H3>
|
|
|
4543 |
<B>Encoding number</B>: 16<P>
|
|
|
4544 |
<PRE>
|
|
|
4545 |
-> NTEST
|
|
|
4546 |
</PRE>
|
|
|
4547 |
Signifies "not comparable" test.
|
|
|
4548 |
<P>
|
|
|
4549 |
With all operands <CODE>SHAPE</CODE>s except <CODE>FLOATING</CODE>,
|
|
|
4550 |
this comparison is always false.
|
|
|
4551 |
<P>
|
|
|
4552 |
|
|
|
4553 |
<HR>
|
|
|
4554 |
<H2>5.27. <A NAME=M252>OTAGEXP</A></H2>
|
|
|
4555 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
4556 |
<B>Is coding extendable</B>: no<P>
|
|
|
4557 |
This is a auxilliary <CODE>SORT</CODE> used in <I>apply_general_proc</I>.
|
|
|
4558 |
<P>
|
|
|
4559 |
|
|
|
4560 |
<H3>5.27.1. <A NAME=M253>make_otagexp</A></H3>
|
|
|
4561 |
<B>Encoding number</B>: 0<P>
|
|
|
4562 |
<PRE>
|
|
|
4563 |
<I>tgopt</I>: OPTION(TAG <I>x</I>)
|
|
|
4564 |
<I>e</I>: EXP <I>x</I>
|
|
|
4565 |
-> OTAGEXP
|
|
|
4566 |
</PRE>
|
|
|
4567 |
<I>e</I> is evaluated and its value is the actual caller parameter.
|
|
|
4568 |
If <I>tgopt</I> is present, the <CODE>TAG</CODE> will be bound to
|
|
|
4569 |
the final value of caller parameter in the <I>postlude</I> part of
|
|
|
4570 |
the <I>apply_general_proc</I>.
|
|
|
4571 |
<P>
|
|
|
4572 |
|
|
|
4573 |
<HR>
|
|
|
4574 |
<H2>5.28. <A NAME=M308>PROCPROPS</A></H2>
|
|
|
4575 |
<B>Number of encoding bits</B>: 4<BR>
|
|
|
4576 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4577 |
<CODE>PROCPROPS</CODE> is a set of properties ascribed to procedure
|
|
|
4578 |
definitions and calls.
|
|
|
4579 |
<P>
|
|
|
4580 |
|
|
|
4581 |
<H3>5.28.1. <A NAME=M256>procprops_apply_token</A></H3>
|
|
|
4582 |
<B>Encoding number</B>: 1<P>
|
|
|
4583 |
<PRE>
|
|
|
4584 |
<I>token_value</I>: TOKEN
|
|
|
4585 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4586 |
-> PROCPROPS
|
|
|
4587 |
</PRE>
|
|
|
4588 |
The token is applied to the arguments to give a <CODE>PROCPROPS</CODE>.
|
|
|
4589 |
<P>
|
|
|
4590 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
4591 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
4592 |
<CODE>SORT</CODE>s of its parameters in the order specified.
|
|
|
4593 |
<P>
|
|
|
4594 |
|
|
|
4595 |
<H3>5.28.2. <A NAME=M257>procprops_cond</A></H3>
|
|
|
4596 |
<B>Encoding number</B>: 2<P>
|
|
|
4597 |
<PRE>
|
|
|
4598 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
4599 |
<I>e1</I>: BITSTREAM PROCPROPS
|
|
|
4600 |
<I>e2</I>: BITSTREAM PROCPROPS
|
|
|
4601 |
-> PROCPROPS
|
|
|
4602 |
</PRE>
|
|
|
4603 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
4604 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
4605 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
4606 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
4607 |
and <I>e1</I> is ignored and never processed.
|
|
|
4608 |
<P>
|
|
|
4609 |
<P>
|
|
|
4610 |
|
|
|
4611 |
<H3>5.28.3. <A NAME=M258>add_procprops</A></H3>
|
|
|
4612 |
<B>Encoding number</B>: 3<P>
|
|
|
4613 |
<PRE>
|
|
|
4614 |
<I>arg1</I>: PROCPROPS
|
|
|
4615 |
<I>arg2</I>: PROCPROPS
|
|
|
4616 |
-> PROCPROPS
|
|
|
4617 |
</PRE>
|
|
|
4618 |
Delivers the join of <I>arg1</I> and <I>arg2</I>.
|
|
|
4619 |
<P>
|
|
|
4620 |
|
|
|
4621 |
<H3>5.28.4. <A NAME=M259>check_stack</A></H3>
|
|
|
4622 |
<B>Encoding number</B>: 4<P>
|
|
|
4623 |
<PRE>
|
|
|
4624 |
-> PROCPROPS
|
|
|
4625 |
</PRE>
|
|
|
4626 |
The procedure body is required to check for stack overflow.
|
|
|
4627 |
<P>
|
|
|
4628 |
|
|
|
4629 |
<H3>5.28.5. <A NAME=M260>inline</A></H3>
|
|
|
4630 |
<B>Encoding number</B>: 5<P>
|
|
|
4631 |
<PRE>
|
|
|
4632 |
-> PROCPROPS
|
|
|
4633 |
</PRE>
|
|
|
4634 |
The procedure body is a good candidate for inlining at its application.
|
|
|
4635 |
<P>
|
|
|
4636 |
|
|
|
4637 |
<H3>5.28.6. <A NAME=M261>no_long_jump_dest</A></H3>
|
|
|
4638 |
<B>Encoding number</B>: 6<P>
|
|
|
4639 |
<PRE>
|
|
|
4640 |
-> PROCPROPS
|
|
|
4641 |
</PRE>
|
|
|
4642 |
The procedure body will contain no label which is the destination
|
|
|
4643 |
of a long_jump.
|
|
|
4644 |
<P>
|
|
|
4645 |
|
|
|
4646 |
<H3>5.28.7. <A NAME=M262>untidy</A></H3>
|
|
|
4647 |
<B>Encoding number</B>: 7<P>
|
|
|
4648 |
<PRE>
|
|
|
4649 |
-> PROCPROPS
|
|
|
4650 |
</PRE>
|
|
|
4651 |
The procedure body may be exited using an <I>untidy_return</I>.
|
|
|
4652 |
<P>
|
|
|
4653 |
|
|
|
4654 |
<H3>5.28.8. <A NAME=M263>var_callees</A></H3>
|
|
|
4655 |
<B>Encoding number</B>: 8<P>
|
|
|
4656 |
<PRE>
|
|
|
4657 |
-> PROCPROPS
|
|
|
4658 |
</PRE>
|
|
|
4659 |
Applications of the procedure may have different numbers of actual
|
|
|
4660 |
callee parameters.
|
|
|
4661 |
<P>
|
|
|
4662 |
|
|
|
4663 |
<H3>5.28.9. <A NAME=M264>var_callers</A></H3>
|
|
|
4664 |
<B>Encoding number</B>: 9<P>
|
|
|
4665 |
<PRE>
|
|
|
4666 |
-> PROCPROPS
|
|
|
4667 |
</PRE>
|
|
|
4668 |
Applications of the procedure may have different numbers of actual
|
|
|
4669 |
caller parameters.
|
|
|
4670 |
<P>
|
|
|
4671 |
|
|
|
4672 |
<HR>
|
|
|
4673 |
<H2>5.29. <A NAME=M266>PROPS</A></H2>
|
|
|
4674 |
A <CODE>PROPS</CODE> is an assemblage of program information. This
|
|
|
4675 |
standard offers various ways of constructing a <CODE>PROPS</CODE>
|
|
|
4676 |
- i.e. it defines kinds of information which it is useful to express.
|
|
|
4677 |
These are:
|
|
|
4678 |
<UL>
|
|
|
4679 |
<LI>definitions of <CODE>AL_TAG</CODE>s standing for <CODE>ALIGNMENT</CODE>s;
|
|
|
4680 |
<LI>declarations of <CODE>TAG</CODE>s standing for <CODE>EXP</CODE>s;
|
|
|
4681 |
<LI>definitions of the <CODE>EXP</CODE>s for which <CODE>TAG</CODE>s
|
|
|
4682 |
stand;
|
|
|
4683 |
<LI>declarations of <CODE>TOKEN</CODE>s standing for pieces of TDF
|
|
|
4684 |
program;
|
|
|
4685 |
<LI>definitions of the pieces of TDF program for which <CODE>TOKEN</CODE>s
|
|
|
4686 |
stand;
|
|
|
4687 |
<LI>linkage and naming information;
|
|
|
4688 |
<LI>version information
|
|
|
4689 |
</UL>
|
|
|
4690 |
<CODE>PROPS</CODE> giving diagnostic information are described in
|
|
|
4691 |
a separate document.
|
|
|
4692 |
<P>
|
|
|
4693 |
The standard can be extended by the definition of new kinds of
|
|
|
4694 |
<CODE>PROPS</CODE> information and new <CODE>PROPS</CODE> constructs
|
|
|
4695 |
for expressing them; and private standards can define new kinds of
|
|
|
4696 |
information and corresponding constructs without disruption to adherents
|
|
|
4697 |
to the present standard.
|
|
|
4698 |
<P>
|
|
|
4699 |
Each <CODE>GROUP</CODE> of <CODE>UNIT</CODE>s is identified by a unit
|
|
|
4700 |
identification - a <CODE>TDFIDENT</CODE>. All the <CODE>UNIT</CODE>s
|
|
|
4701 |
in that <CODE>GROUP</CODE> are of the same kind.
|
|
|
4702 |
<P>
|
|
|
4703 |
In addition there is a <I>tld</I> <CODE>UNIT</CODE>, see
|
|
|
4704 |
<A HREF="spec11.html#17">The TDF encoding</A>.
|
|
|
4705 |
<P>
|
|
|
4706 |
|
|
|
4707 |
<HR>
|
|
|
4708 |
<H2>5.30. <A NAME=M309>ROUNDING_MODE</A></H2>
|
|
|
4709 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
4710 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4711 |
<CODE>ROUNDING_MODE</CODE> specifies the way rounding is to be performed
|
|
|
4712 |
in floating point arithmetic.
|
|
|
4713 |
<P>
|
|
|
4714 |
|
|
|
4715 |
<H3>5.30.1. <A NAME=M268>rounding_mode_apply_token</A></H3>
|
|
|
4716 |
<B>Encoding number</B>: 1<P>
|
|
|
4717 |
<PRE>
|
|
|
4718 |
<I>token_value</I>: TOKEN
|
|
|
4719 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4720 |
-> ROUNDING_MODE
|
|
|
4721 |
</PRE>
|
|
|
4722 |
The token is applied to the arguments to give a <CODE>ROUNDING_MODE</CODE>.
|
|
|
4723 |
<P>
|
|
|
4724 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
4725 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
4726 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
4727 |
<P>
|
|
|
4728 |
|
|
|
4729 |
<H3>5.30.2. <A NAME=M269>rounding_mode_cond</A></H3>
|
|
|
4730 |
<B>Encoding number</B>: 2<P>
|
|
|
4731 |
<PRE>
|
|
|
4732 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
4733 |
<I>e1</I>: BITSTREAM ROUNDING_MODE
|
|
|
4734 |
<I>e2</I>: BITSTREAM ROUNDING_MODE
|
|
|
4735 |
-> ROUNDING_MODE
|
|
|
4736 |
</PRE>
|
|
|
4737 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
4738 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
4739 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
4740 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
4741 |
and <I>e1</I> is ignored and never processed.
|
|
|
4742 |
<P>
|
|
|
4743 |
|
|
|
4744 |
<H3>5.30.3. <A NAME=M270>round_as_state</A></H3>
|
|
|
4745 |
<B>Encoding number</B>: 3<P>
|
|
|
4746 |
<PRE>
|
|
|
4747 |
-> ROUNDING_MODE
|
|
|
4748 |
</PRE>
|
|
|
4749 |
Round as specified by the current state of the machine.
|
|
|
4750 |
<P>
|
|
|
4751 |
|
|
|
4752 |
<H3>5.30.4. <A NAME=M271>to_nearest</A></H3>
|
|
|
4753 |
<B>Encoding number</B>: 4<P>
|
|
|
4754 |
<PRE>
|
|
|
4755 |
-> ROUNDING_MODE
|
|
|
4756 |
</PRE>
|
|
|
4757 |
Signifies rounding to nearest. The effect when the number lies half-way
|
|
|
4758 |
is not specified.
|
|
|
4759 |
<P>
|
|
|
4760 |
|
|
|
4761 |
<H3>5.30.5. <A NAME=M272>toward_larger</A></H3>
|
|
|
4762 |
<B>Encoding number</B>: 5<P>
|
|
|
4763 |
<PRE>
|
|
|
4764 |
-> ROUNDING_MODE
|
|
|
4765 |
</PRE>
|
|
|
4766 |
Signifies rounding toward next largest.
|
|
|
4767 |
<P>
|
|
|
4768 |
|
|
|
4769 |
<H3>5.30.6. <A NAME=M273>toward_smaller</A></H3>
|
|
|
4770 |
<B>Encoding number</B>: 6<P>
|
|
|
4771 |
<PRE>
|
|
|
4772 |
-> ROUNDING_MODE
|
|
|
4773 |
</PRE>
|
|
|
4774 |
Signifies rounding toward next smallest.
|
|
|
4775 |
<P>
|
|
|
4776 |
|
|
|
4777 |
<H3>5.30.7. <A NAME=M274>toward_zero</A></H3>
|
|
|
4778 |
<B>Encoding number</B>: 7<P>
|
|
|
4779 |
<PRE>
|
|
|
4780 |
-> ROUNDING_MODE
|
|
|
4781 |
</PRE>
|
|
|
4782 |
Signifies rounding toward zero.
|
|
|
4783 |
<P>
|
|
|
4784 |
|
|
|
4785 |
<HR>
|
|
|
4786 |
<H2>5.31. <A NAME=M310>SHAPE</A></H2>
|
|
|
4787 |
<B>Number of encoding bits</B>: 4<BR>
|
|
|
4788 |
<B>Is coding extendable</B>: yes<P>
|
|
|
4789 |
<CODE>SHAPE</CODE>s express symbolic size and representation information
|
|
|
4790 |
about run time values.
|
|
|
4791 |
<P>
|
|
|
4792 |
<CODE>SHAPE</CODE>s are constructed from primitive <CODE>SHAPE</CODE>s
|
|
|
4793 |
which describe values such as procedures and integers, and recursively
|
|
|
4794 |
from compound construction in terms of other <CODE>SHAPE</CODE>s.
|
|
|
4795 |
<P>
|
|
|
4796 |
|
|
|
4797 |
<H3>5.31.1. <A NAME=M276>shape_apply_token</A></H3>
|
|
|
4798 |
<B>Encoding number</B>: 1<P>
|
|
|
4799 |
<PRE>
|
|
|
4800 |
<I>token_value</I>: TOKEN
|
|
|
4801 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
4802 |
-> SHAPE
|
|
|
4803 |
</PRE>
|
|
|
4804 |
The token is applied to the arguments to give a <CODE>SHAPE</CODE>.
|
|
|
4805 |
<P>
|
|
|
4806 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
4807 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
4808 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
4809 |
<P>
|
|
|
4810 |
|
|
|
4811 |
<H3>5.31.2. <A NAME=M277>shape_cond</A></H3>
|
|
|
4812 |
<B>Encoding number</B>: 2<P>
|
|
|
4813 |
<PRE>
|
|
|
4814 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
4815 |
<I>e1</I>: BITSTREAM SHAPE
|
|
|
4816 |
<I>e2</I>: BITSTREAM SHAPE
|
|
|
4817 |
-> SHAPE
|
|
|
4818 |
</PRE>
|
|
|
4819 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
4820 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
4821 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
4822 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
4823 |
and <I>e1</I> is ignored and never processed.
|
|
|
4824 |
<P>
|
|
|
4825 |
|
|
|
4826 |
<H3>5.31.3. <A NAME=M278>bitfield</A></H3>
|
|
|
4827 |
<B>Encoding number</B>: 3<P>
|
|
|
4828 |
<PRE>
|
|
|
4829 |
<I>bf_var</I>: BITFIELD_VARIETY
|
|
|
4830 |
-> SHAPE
|
|
|
4831 |
</PRE>
|
|
|
4832 |
A <CODE>BITFIELD</CODE> is used to represent a pattern of bits which
|
|
|
4833 |
will be packed, provided that the <I>variety_enclosed</I> constraints
|
|
|
4834 |
are not violated. (see See <A HREF="spec10.html#66">section 7.24</A>)<P>
|
|
|
4835 |
A <CODE>BITFIELD_VARIETY</CODE> specifies the number of bits and whether
|
|
|
4836 |
they are considered to be signed.
|
|
|
4837 |
<P>
|
|
|
4838 |
There are very few operations on <CODE>BITFIELD</CODE>s, which have
|
|
|
4839 |
to be converted to <CODE>INTEGER</CODE>s before arithmetic can be
|
|
|
4840 |
performed on them.
|
|
|
4841 |
<P>
|
|
|
4842 |
An installer may place a limit on the number of bits it implements.
|
|
|
4843 |
See <A HREF="spec10.html#68">Permitted limits</A>.
|
|
|
4844 |
<P>
|
|
|
4845 |
|
|
|
4846 |
<H3>5.31.4. <A NAME=M279>bottom</A></H3>
|
|
|
4847 |
<B>Encoding number</B>: 4<P>
|
|
|
4848 |
<PRE>
|
|
|
4849 |
-> SHAPE
|
|
|
4850 |
</PRE>
|
|
|
4851 |
<CODE>BOTTOM</CODE> is the <CODE>SHAPE</CODE> which describes a piece
|
|
|
4852 |
of program which does not evaluate to any result. Examples include
|
|
|
4853 |
<I>goto</I> and <I>return</I>.
|
|
|
4854 |
<P>
|
|
|
4855 |
If <CODE>BOTTOM</CODE> is a parameter to any other <CODE>SHAPE</CODE>
|
|
|
4856 |
constructor, the result is <CODE>BOTTOM</CODE>.
|
|
|
4857 |
<P>
|
|
|
4858 |
|
|
|
4859 |
<H3>5.31.5. <A NAME=M280>compound</A></H3>
|
|
|
4860 |
<B>Encoding number</B>: 5<P>
|
|
|
4861 |
<PRE>
|
|
|
4862 |
<I>sz</I>: EXP OFFSET(<I>x</I>, y)
|
|
|
4863 |
-> SHAPE
|
|
|
4864 |
</PRE>
|
|
|
4865 |
The <CODE>SHAPE</CODE> constructor <CODE>COMPOUND</CODE> describes
|
|
|
4866 |
cartesian products and unions.
|
|
|
4867 |
<P>
|
|
|
4868 |
The alignments <I>x</I> and <I>y</I> will be <I>alignment</I>(<I>sx</I>)
|
|
|
4869 |
and <I>alignment</I>(<I>sy</I>) for some <CODE>SHAPE</CODE>s <I>sx</I>
|
|
|
4870 |
and <I>sy</I>.
|
|
|
4871 |
<P>
|
|
|
4872 |
<I>sz</I> will evaluate to a constant, non-negative <CODE>OFFSET</CODE>
|
|
|
4873 |
(see <A HREF="#M169">offset_pad</A>). The resulting
|
|
|
4874 |
<CODE>SHAPE</CODE> describes a value whose size is given by <I>sz</I>.
|
|
|
4875 |
<P>
|
|
|
4876 |
|
|
|
4877 |
<H3>5.31.6. <A NAME=M282>floating</A></H3>
|
|
|
4878 |
<B>Encoding number</B>: 6<P>
|
|
|
4879 |
<PRE>
|
|
|
4880 |
<I>fv</I>: FLOATING_VARIETY
|
|
|
4881 |
-> SHAPE
|
|
|
4882 |
</PRE>
|
|
|
4883 |
Most of the floating point arithmetic operations, <I>floating_plus</I>,
|
|
|
4884 |
<I>floating_minus</I> etc., are defined to work in the same way on
|
|
|
4885 |
different kinds of floating point number. If these operations have
|
|
|
4886 |
more than one argument the arguments have to be of the same kind,
|
|
|
4887 |
and the result is of the same kind.
|
|
|
4888 |
<P>
|
|
|
4889 |
See <A HREF="spec10.html#57">Representing floating point</A>.
|
|
|
4890 |
<P>
|
|
|
4891 |
An installer may limit the <CODE>FLOATING_VARIETY</CODE>s it can represent.
|
|
|
4892 |
A statement of any such limits shall be part of the specification
|
|
|
4893 |
of an installer. See
|
|
|
4894 |
<A HREF="spec10.html#57">Representing floating point</A>.
|
|
|
4895 |
<P>
|
|
|
4896 |
|
|
|
4897 |
<H3>5.31.7. <A NAME=M283>integer</A></H3>
|
|
|
4898 |
<B>Encoding number</B>: 7<P>
|
|
|
4899 |
<PRE>
|
|
|
4900 |
<I>var</I>: VARIETY
|
|
|
4901 |
-> SHAPE
|
|
|
4902 |
</PRE>
|
|
|
4903 |
The different kinds of <CODE>INTEGER</CODE> are distinguished by having
|
|
|
4904 |
different <CODE>VARIETY</CODE>s. A fundamental <CODE>VARIETY</CODE>
|
|
|
4905 |
(not a <CODE>TOKEN</CODE> or conditional) is represented by two
|
|
|
4906 |
<CODE>SIGNED_NAT</CODE>s, respectively the lower and upper bounds
|
|
|
4907 |
(inclusive) of the set of values belonging to the <CODE>VARIETY</CODE>.
|
|
|
4908 |
<P>
|
|
|
4909 |
Most architectures require that dyadic integer arithmetic operations
|
|
|
4910 |
take arguments of the same size, and so TDF does likewise. Because
|
|
|
4911 |
TDF is completely architecture neutral and makes no assumptions about
|
|
|
4912 |
word length, this means that the <CODE>VARIETY</CODE>s of the two
|
|
|
4913 |
arguments must be identical. An example illustrates this. A piece
|
|
|
4914 |
of TDF which attempted to add two values whose <CODE>SHAPE</CODE>s
|
|
|
4915 |
were:
|
|
|
4916 |
<PRE>
|
|
|
4917 |
INTEGER(0, 60000) <I>and</I> INTEGER(0, 30000)
|
|
|
4918 |
</PRE>
|
|
|
4919 |
would be undefined. The reason is that without knowledge of the target
|
|
|
4920 |
architecture's word length, it is impossible to guarantee that the
|
|
|
4921 |
two values are going to be represented in the same number of bytes.
|
|
|
4922 |
On a 16-bit machine they probably would, but not on a 15-bit machine.
|
|
|
4923 |
The only way to ensure that two <CODE>INTEGER</CODE>s are going to
|
|
|
4924 |
be represented in the same way in all machines is to stipulate that
|
|
|
4925 |
their <CODE>VARIETY</CODE>s are exactly the same.
|
|
|
4926 |
<P>
|
|
|
4927 |
When any construct delivering an <CODE>INTEGER</CODE> of a given
|
|
|
4928 |
<CODE>VARIETY</CODE> produces a result which is not representable
|
|
|
4929 |
in the space which an installer has chosen to represent that
|
|
|
4930 |
<CODE>VARIETY</CODE>, an integer overflow occurs. Whether it occurs
|
|
|
4931 |
in a particular case depends on the target, because the installers'
|
|
|
4932 |
decisions on representation are inherently target-defined.
|
|
|
4933 |
<P>
|
|
|
4934 |
A particular installer may limit the ranges of integers that it implements.
|
|
|
4935 |
See <A HREF="spec10.html#51">Representing integers</A>.
|
|
|
4936 |
<P>
|
|
|
4937 |
|
|
|
4938 |
<H3>5.31.8. <A NAME=M284>nof</A></H3>
|
|
|
4939 |
<B>Encoding number</B>: 8<P>
|
|
|
4940 |
<PRE>
|
|
|
4941 |
<I>n</I>: NAT
|
|
|
4942 |
<I>s</I>: SHAPE
|
|
|
4943 |
-> SHAPE
|
|
|
4944 |
</PRE>
|
|
|
4945 |
The <CODE>NOF</CODE> constructor describes the <CODE>SHAPE</CODE>
|
|
|
4946 |
of a value consisting of an array of <I>n</I> values of the same
|
|
|
4947 |
<CODE>SHAPE</CODE>, <I>s</I>.
|
|
|
4948 |
<P>
|
|
|
4949 |
|
|
|
4950 |
<H3>5.31.9. <A NAME=M285>offset</A></H3>
|
|
|
4951 |
<B>Encoding number</B>: 9<P>
|
|
|
4952 |
<PRE>
|
|
|
4953 |
<I>arg1</I>: ALIGNMENT
|
|
|
4954 |
<I>arg2</I>: ALIGNMENT
|
|
|
4955 |
-> SHAPE
|
|
|
4956 |
</PRE>
|
|
|
4957 |
The <CODE>SHAPE</CODE> constructor <CODE>OFFSET</CODE> describes values
|
|
|
4958 |
which represent the differences between <CODE>POINTER</CODE>s, that
|
|
|
4959 |
is they measure offsets in memory. It should be emphasised that these
|
|
|
4960 |
are in general run-time values.
|
|
|
4961 |
<P>
|
|
|
4962 |
An <CODE>OFFSET</CODE> measures the displacement from the value indicated
|
|
|
4963 |
by a <CODE>POINTER</CODE>(<I>arg1</I>) to the value indicated by a
|
|
|
4964 |
<CODE>POINTER</CODE>(<I>arg2</I>). Such an offset is only defined
|
|
|
4965 |
if the <CODE>POINTER</CODE>s are derived from the same original
|
|
|
4966 |
<CODE>POINTER</CODE>.
|
|
|
4967 |
<P>
|
|
|
4968 |
An <CODE>OFFSET</CODE> may also measure the displacement from a
|
|
|
4969 |
<CODE>POINTER</CODE> to the start of a <CODE>BITFIELD_VARIETY</CODE>,
|
|
|
4970 |
or from the start of one <CODE>BITFIELD_VARIETY</CODE> to the start
|
|
|
4971 |
of another. Hence, unlike the argument of <I>pointer</I>, <I>arg1</I>
|
|
|
4972 |
or
|
|
|
4973 |
<I>arg2</I> may consist entirely of <CODE>BITFIELD_VARIETY</CODE>s.
|
|
|
4974 |
<P>
|
|
|
4975 |
The set <I>arg1</I> will include the set <I>arg2</I>.
|
|
|
4976 |
<P>
|
|
|
4977 |
See <A HREF="spec10.html#26">Memory Model</A>.
|
|
|
4978 |
<P>
|
|
|
4979 |
|
|
|
4980 |
<H3>5.31.10. <A NAME=M286>pointer</A></H3>
|
|
|
4981 |
<B>Encoding number</B>: 10<P>
|
|
|
4982 |
<PRE>
|
|
|
4983 |
<I>arg</I>: ALIGNMENT
|
|
|
4984 |
-> SHAPE
|
|
|
4985 |
</PRE>
|
|
|
4986 |
A <CODE>POINTER</CODE> is a value which points to space allocated
|
|
|
4987 |
in a computer's memory. The <CODE>POINTER</CODE> constructor takes
|
|
|
4988 |
an
|
|
|
4989 |
<CODE>ALIGNMENT</CODE> argument. This argument will not consist entirely
|
|
|
4990 |
of <CODE>BITFIELD_VARIETY</CODE>s. See <A HREF="spec10.html#26">Memory
|
|
|
4991 |
Model</A>.
|
|
|
4992 |
<P>
|
|
|
4993 |
|
|
|
4994 |
<H3>5.31.11. <A NAME=M287>proc</A></H3>
|
|
|
4995 |
<B>Encoding number</B>: 11<P>
|
|
|
4996 |
<PRE>
|
|
|
4997 |
-> SHAPE
|
|
|
4998 |
</PRE>
|
|
|
4999 |
<CODE>PROC</CODE> is the <CODE>SHAPE</CODE> which describes pieces
|
|
|
5000 |
of program.
|
|
|
5001 |
<P>
|
|
|
5002 |
|
|
|
5003 |
<H3>5.31.12. <A NAME=M288>top</A></H3>
|
|
|
5004 |
<B>Encoding number</B>: 12<P>
|
|
|
5005 |
<PRE>
|
|
|
5006 |
-> SHAPE
|
|
|
5007 |
</PRE>
|
|
|
5008 |
<CODE>TOP</CODE> is the <CODE>SHAPE</CODE> which describes pieces
|
|
|
5009 |
of program which return no useful value. <I>assign</I> is an example:
|
|
|
5010 |
it performs an assignment, but does not deliver any useful value.
|
|
|
5011 |
<P>
|
|
|
5012 |
|
|
|
5013 |
<HR>
|
|
|
5014 |
<H2>5.32. <A NAME=M311>SIGNED_NAT</A></H2>
|
|
|
5015 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
5016 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5017 |
These are positive or negative integers of unbounded size.
|
|
|
5018 |
<P>
|
|
|
5019 |
|
|
|
5020 |
<H3>5.32.1. <A NAME=M290>signed_nat_apply_token</A></H3>
|
|
|
5021 |
<B>Encoding number</B>: 1<P>
|
|
|
5022 |
<PRE>
|
|
|
5023 |
<I>token_value</I>: TOKEN
|
|
|
5024 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
5025 |
-> SIGNED_NAT
|
|
|
5026 |
</PRE>
|
|
|
5027 |
The token is applied to the arguments to give a <CODE>SIGNED_NAT</CODE>.
|
|
|
5028 |
<P>
|
|
|
5029 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
5030 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
5031 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
5032 |
<P>
|
|
|
5033 |
|
|
|
5034 |
<H3>5.32.2. <A NAME=M291>signed_nat_cond</A></H3>
|
|
|
5035 |
<B>Encoding number</B>: 2<P>
|
|
|
5036 |
<PRE>
|
|
|
5037 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
5038 |
<I>e1</I>: BITSTREAM SIGNED_NAT
|
|
|
5039 |
<I>e2</I>: BITSTREAM SIGNED_NAT
|
|
|
5040 |
-> SIGNED_NAT
|
|
|
5041 |
</PRE>
|
|
|
5042 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
5043 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
5044 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
5045 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
5046 |
and <I>e1</I> is ignored and never processed.
|
|
|
5047 |
<P>
|
|
|
5048 |
|
|
|
5049 |
<H3>5.32.3. <A NAME=M292>computed_signed_nat</A></H3>
|
|
|
5050 |
<B>Encoding number</B>: 3<P>
|
|
|
5051 |
<PRE>
|
|
|
5052 |
<I>arg</I>: EXP INTEGER(<I>v</I>)
|
|
|
5053 |
-> SIGNED_NAT
|
|
|
5054 |
</PRE>
|
|
|
5055 |
<I>arg</I> will be an install-time constant. The result is that constant.
|
|
|
5056 |
<P>
|
|
|
5057 |
|
|
|
5058 |
<H3>5.32.4. <A NAME=M293>make_signed_nat</A></H3>
|
|
|
5059 |
<B>Encoding number</B>: 4<P>
|
|
|
5060 |
<PRE>
|
|
|
5061 |
<I>neg</I>: TDFBOOL
|
|
|
5062 |
<I>n</I>: TDFINT
|
|
|
5063 |
-> SIGNED_NAT
|
|
|
5064 |
</PRE>
|
|
|
5065 |
<I>n</I> is a non-negative integer of unbounded magnitude. The result
|
|
|
5066 |
is negative if and only if <I>neg</I> is true.
|
|
|
5067 |
<P>
|
|
|
5068 |
|
|
|
5069 |
<H3>5.32.5. <A NAME=M294>snat_from_nat</A></H3>
|
|
|
5070 |
<B>Encoding number</B>: 5<P>
|
|
|
5071 |
<PRE>
|
|
|
5072 |
<I>neg</I>: BOOL
|
|
|
5073 |
<I>n</I>: NAT
|
|
|
5074 |
-> SIGNED_NAT
|
|
|
5075 |
</PRE>
|
|
|
5076 |
The result is negated if and only if <I>neg</I> is true.
|
|
|
5077 |
<P>
|
|
|
5078 |
|
|
|
5079 |
<HR>
|
|
|
5080 |
<H2>5.33. <A NAME=M295>SORTNAME</A></H2>
|
|
|
5081 |
<B>Number of encoding bits</B>: 5<BR>
|
|
|
5082 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5083 |
These are the names of the <CODE>SORT</CODE>s which can be parameters
|
|
|
5084 |
of <CODE>TOKEN</CODE> definitions.
|
|
|
5085 |
<P>
|
|
|
5086 |
|
|
|
5087 |
<H3>5.33.1. <A NAME=M296A>access</A></H3>
|
|
|
5088 |
<B>Encoding number</B>: 1<P>
|
|
|
5089 |
<PRE>
|
|
|
5090 |
-> SORTNAME
|
|
|
5091 |
</PRE>
|
|
|
5092 |
|
|
|
5093 |
<H3>5.33.2. <A NAME=M297A>al_tag</A></H3>
|
|
|
5094 |
<B>Encoding number</B>: 2<P>
|
|
|
5095 |
<PRE>
|
|
|
5096 |
-> SORTNAME
|
|
|
5097 |
</PRE>
|
|
|
5098 |
|
|
|
5099 |
<H3>5.33.3. <A NAME=M298>alignment_sort</A></H3>
|
|
|
5100 |
<B>Encoding number</B>: 3<P>
|
|
|
5101 |
<PRE>
|
|
|
5102 |
-> SORTNAME
|
|
|
5103 |
</PRE>
|
|
|
5104 |
|
|
|
5105 |
<H3>5.33.4. <A NAME=M299A>bitfield_variety</A></H3>
|
|
|
5106 |
<B>Encoding number</B>: 4<P>
|
|
|
5107 |
<PRE>
|
|
|
5108 |
-> SORTNAME
|
|
|
5109 |
</PRE>
|
|
|
5110 |
|
|
|
5111 |
<H3>5.33.5. <A NAME=M300A>bool</A></H3>
|
|
|
5112 |
<B>Encoding number</B>: 5<P>
|
|
|
5113 |
<PRE>
|
|
|
5114 |
-> SORTNAME
|
|
|
5115 |
</PRE>
|
|
|
5116 |
|
|
|
5117 |
<H3>5.33.6. <A NAME=M301A>error_treatment</A></H3>
|
|
|
5118 |
<B>Encoding number</B>: 6<P>
|
|
|
5119 |
<PRE>
|
|
|
5120 |
-> SORTNAME
|
|
|
5121 |
</PRE>
|
|
|
5122 |
|
|
|
5123 |
<H3>5.33.7. <A NAME=M302A>exp</A></H3>
|
|
|
5124 |
<B>Encoding number</B>: 7<P>
|
|
|
5125 |
<PRE>
|
|
|
5126 |
-> SORTNAME
|
|
|
5127 |
</PRE>
|
|
|
5128 |
The <CODE>SORT</CODE> of <CODE>EXP</CODE>.
|
|
|
5129 |
<P>
|
|
|
5130 |
|
|
|
5131 |
<H3>5.33.8. <A NAME=M303A>floating_variety</A></H3>
|
|
|
5132 |
<B>Encoding number</B>: 8<P>
|
|
|
5133 |
<PRE>
|
|
|
5134 |
-> SORTNAME
|
|
|
5135 |
</PRE>
|
|
|
5136 |
|
|
|
5137 |
<H3>5.33.9. <A NAME=M304>foreign_sort</A></H3>
|
|
|
5138 |
<B>Encoding number</B>: 9<P>
|
|
|
5139 |
<PRE>
|
|
|
5140 |
<I>foreign_name</I>: STRING<I>(k, n)</I>
|
|
|
5141 |
-> SORTNAME
|
|
|
5142 |
</PRE>
|
|
|
5143 |
This <CODE>SORT</CODE> enables unanticipated kinds of information
|
|
|
5144 |
to be placed in TDF.
|
|
|
5145 |
<P>
|
|
|
5146 |
|
|
|
5147 |
<H3>5.33.10. <A NAME=M305A>label</A></H3>
|
|
|
5148 |
<B>Encoding number</B>: 10<P>
|
|
|
5149 |
<PRE>
|
|
|
5150 |
-> SORTNAME
|
|
|
5151 |
</PRE>
|
|
|
5152 |
|
|
|
5153 |
<H3>5.33.11. <A NAME=M306A>nat</A></H3>
|
|
|
5154 |
<B>Encoding number</B>: 11<P>
|
|
|
5155 |
<PRE>
|
|
|
5156 |
-> SORTNAME
|
|
|
5157 |
</PRE>
|
|
|
5158 |
|
|
|
5159 |
<H3>5.33.12. <A NAME=M307A>ntest</A></H3>
|
|
|
5160 |
<B>Encoding number</B>: 12<P>
|
|
|
5161 |
<PRE>
|
|
|
5162 |
-> SORTNAME
|
|
|
5163 |
</PRE>
|
|
|
5164 |
|
|
|
5165 |
<H3>5.33.13. <A NAME=M308A>procprops</A></H3>
|
|
|
5166 |
<B>Encoding number</B>: 13<P>
|
|
|
5167 |
<PRE>
|
|
|
5168 |
-> SORTNAME
|
|
|
5169 |
</PRE>
|
|
|
5170 |
|
|
|
5171 |
<H3>5.33.14. <A NAME=M309A>rounding_mode</A></H3>
|
|
|
5172 |
<B>Encoding number</B>: 14<P>
|
|
|
5173 |
<PRE>
|
|
|
5174 |
-> SORTNAME
|
|
|
5175 |
</PRE>
|
|
|
5176 |
|
|
|
5177 |
<H3>5.33.15. <A NAME=M310A>shape</A></H3>
|
|
|
5178 |
<B>Encoding number</B>: 15<P>
|
|
|
5179 |
<PRE>
|
|
|
5180 |
-> SORTNAME
|
|
|
5181 |
</PRE>
|
|
|
5182 |
|
|
|
5183 |
<H3>5.33.16. <A NAME=M311A>signed_nat</A></H3>
|
|
|
5184 |
<B>Encoding number</B>: 16<P>
|
|
|
5185 |
<PRE>
|
|
|
5186 |
-> SORTNAME
|
|
|
5187 |
</PRE>
|
|
|
5188 |
|
|
|
5189 |
<H3>5.33.17. <A NAME=M317A>string</A></H3>
|
|
|
5190 |
<B>Encoding number</B>: 17<P>
|
|
|
5191 |
<PRE>
|
|
|
5192 |
-> SORTNAME
|
|
|
5193 |
</PRE>
|
|
|
5194 |
|
|
|
5195 |
<H3>5.33.18. <A NAME=M322A>tag</A></H3>
|
|
|
5196 |
<B>Encoding number</B>: 18<P>
|
|
|
5197 |
<PRE>
|
|
|
5198 |
-> SORTNAME
|
|
|
5199 |
</PRE>
|
|
|
5200 |
The <CODE>SORT</CODE> of <CODE>TAG</CODE>.
|
|
|
5201 |
<P>
|
|
|
5202 |
|
|
|
5203 |
<H3>5.33.19. <A NAME=M365A>transfer_mode</A></H3>
|
|
|
5204 |
<B>Encoding number</B>: 19<P>
|
|
|
5205 |
<PRE>
|
|
|
5206 |
-> SORTNAME
|
|
|
5207 |
</PRE>
|
|
|
5208 |
|
|
|
5209 |
<H3>5.33.20. <A NAME=M356A>token</A></H3>
|
|
|
5210 |
<B>Encoding number</B>: 20<P>
|
|
|
5211 |
<PRE>
|
|
|
5212 |
<I>result</I>: SORTNAME
|
|
|
5213 |
<I>params</I>: LIST(SORTNAME)
|
|
|
5214 |
-> SORTNAME
|
|
|
5215 |
</PRE>
|
|
|
5216 |
The <CODE>SORTNAME</CODE> of a <CODE>TOKEN</CODE>. Note that it can
|
|
|
5217 |
have tokens as parameters, but not as result.
|
|
|
5218 |
<P>
|
|
|
5219 |
|
|
|
5220 |
<H3>5.33.21. <A NAME=M378A>variety</A></H3>
|
|
|
5221 |
<B>Encoding number</B>: 21<P>
|
|
|
5222 |
<PRE>
|
|
|
5223 |
-> SORTNAME
|
|
|
5224 |
</PRE>
|
|
|
5225 |
|
|
|
5226 |
<HR>
|
|
|
5227 |
<H2>5.34. <A NAME=M317>STRING</A></H2>
|
|
|
5228 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
5229 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5230 |
|
|
|
5231 |
<H3>5.34.1. <A NAME=M318>string_apply_token</A></H3>
|
|
|
5232 |
<B>Encoding number</B>: 1<P>
|
|
|
5233 |
<PRE>
|
|
|
5234 |
<I>token_value</I>: TOKEN
|
|
|
5235 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
5236 |
-> STRING<I>(k, n)</I>
|
|
|
5237 |
</PRE>
|
|
|
5238 |
The token is applied to the arguments to give a <CODE>STRING</CODE>
|
|
|
5239 |
<P>
|
|
|
5240 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
5241 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
5242 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
5243 |
<P>
|
|
|
5244 |
|
|
|
5245 |
<H3>5.34.2. <A NAME=M319>string_cond</A></H3>
|
|
|
5246 |
<B>Encoding number</B>: 2<P>
|
|
|
5247 |
<PRE>
|
|
|
5248 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
5249 |
<I>e1</I>: BITSTREAM STRING
|
|
|
5250 |
<I>e2</I>: BITSTREAM STRING
|
|
|
5251 |
-> STRING<I>(k, n)</I>
|
|
|
5252 |
</PRE>
|
|
|
5253 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
5254 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
5255 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
5256 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
5257 |
and <I>e1</I> is ignored and never processed.
|
|
|
5258 |
<P>
|
|
|
5259 |
|
|
|
5260 |
<H3>5.34.3. <A NAME=M320>concat_string</A></H3>
|
|
|
5261 |
<B>Encoding number</B>: 3<P>
|
|
|
5262 |
<PRE>
|
|
|
5263 |
<I>arg1</I>: STRING<I>(k, n)</I>
|
|
|
5264 |
<I>arg2</I>: STRING<I>(k, m)</I>
|
|
|
5265 |
-> STRING<I>(k, n+m)</I>
|
|
|
5266 |
</PRE>
|
|
|
5267 |
Gives a <CODE>STRING</CODE> which is the concatenation of <I>arg1</I>
|
|
|
5268 |
with <I>arg2</I>.
|
|
|
5269 |
<P>
|
|
|
5270 |
|
|
|
5271 |
<H3>5.34.4. <A NAME=M321>make_string</A></H3>
|
|
|
5272 |
<B>Encoding number</B>: 4<P>
|
|
|
5273 |
<PRE>
|
|
|
5274 |
<I>arg</I>: TDFSTRING<I>(k, n)</I>
|
|
|
5275 |
-> STRING<I>(k, n)</I>
|
|
|
5276 |
</PRE>
|
|
|
5277 |
Delivers the <CODE>STRING</CODE> identical to the <I>arg</I>.
|
|
|
5278 |
<P>
|
|
|
5279 |
|
|
|
5280 |
<HR>
|
|
|
5281 |
<H2>5.35. <A NAME=M322>TAG</A></H2>
|
|
|
5282 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
5283 |
<B>Is coding extendable</B>: yes<BR>
|
|
|
5284 |
<B>Linkable entity identification</B>: <I>tag</I><P>
|
|
|
5285 |
These are used to name values and variables in the run time program.
|
|
|
5286 |
<P>
|
|
|
5287 |
|
|
|
5288 |
<H3>5.35.1. <A NAME=M323>tag_apply_token</A></H3>
|
|
|
5289 |
<B>Encoding number</B>: 2<P>
|
|
|
5290 |
<PRE>
|
|
|
5291 |
<I>token_value</I>: TOKEN
|
|
|
5292 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
5293 |
-> TAG <I>x</I>
|
|
|
5294 |
</PRE>
|
|
|
5295 |
The token is applied to the arguments to give a <CODE>TAG</CODE>.
|
|
|
5296 |
<P>
|
|
|
5297 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
5298 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
5299 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
5300 |
<P>
|
|
|
5301 |
|
|
|
5302 |
<H3>5.35.2. <A NAME=M324>make_tag</A></H3>
|
|
|
5303 |
<B>Encoding number</B>: 1<P>
|
|
|
5304 |
<PRE>
|
|
|
5305 |
<I>tagno</I>: TDFINT
|
|
|
5306 |
-> TAG <I>x</I>
|
|
|
5307 |
</PRE>
|
|
|
5308 |
<I>make_tag</I> produces a <CODE>TAG</CODE> identified by <I>tagno</I>.
|
|
|
5309 |
<P>
|
|
|
5310 |
|
|
|
5311 |
<HR>
|
|
|
5312 |
<H2>5.36. <A NAME=M325>TAGACC</A></H2>
|
|
|
5313 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5314 |
<B>Is coding extendable</B>: no<P>
|
|
|
5315 |
Constructs a pair of a <CODE>TAG</CODE> and an <CODE>OPTION(ACCESS)</CODE>
|
|
|
5316 |
for use in <I>make_proc</I>.
|
|
|
5317 |
<P>
|
|
|
5318 |
|
|
|
5319 |
<H3>5.36.1. <A NAME=M326>make_tagacc</A></H3>
|
|
|
5320 |
<B>Encoding number</B>: 0<P>
|
|
|
5321 |
<PRE>
|
|
|
5322 |
<I>tg</I>: TAG POINTER <I>var_param_alignment</I>
|
|
|
5323 |
<I>acc</I>: OPTION(ACCESS)
|
|
|
5324 |
-> TAGACC
|
|
|
5325 |
</PRE>
|
|
|
5326 |
Constructs the pair for <I>make_proc</I>.
|
|
|
5327 |
<P>
|
|
|
5328 |
|
|
|
5329 |
<HR>
|
|
|
5330 |
<H2>5.37. <A NAME=M327>TAGDEC</A></H2>
|
|
|
5331 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
5332 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5333 |
A <CODE>TAGDEC</CODE> declares a <CODE>TAG</CODE> for incorporation
|
|
|
5334 |
into a <CODE>TAGDEC_PROPS.</CODE><P>
|
|
|
5335 |
|
|
|
5336 |
<H3>5.37.1. <A NAME=M328>make_id_tagdec</A></H3>
|
|
|
5337 |
<B>Encoding number</B>: 1<P>
|
|
|
5338 |
<PRE>
|
|
|
5339 |
<I>t_intro</I>: TDFINT
|
|
|
5340 |
<I>acc</I>: OPTION(ACCESS)
|
|
|
5341 |
<I>signature</I>: OPTION(STRING)
|
|
|
5342 |
<I>x</I>: SHAPE
|
|
|
5343 |
-> TAGDEC
|
|
|
5344 |
</PRE>
|
|
|
5345 |
A <CODE>TAGDEC</CODE> announcing that the <CODE>TAG</CODE>
|
|
|
5346 |
<I>t_intro</I> identifies an <CODE>EXP</CODE> of <CODE>SHAPE</CODE>
|
|
|
5347 |
<I>x</I> is constructed.
|
|
|
5348 |
<P>
|
|
|
5349 |
<I>acc</I> specifies the <CODE>ACCESS</CODE> properties of the
|
|
|
5350 |
<CODE>TAG</CODE>.
|
|
|
5351 |
<P>
|
|
|
5352 |
If there is a <I>make_id_tagdec</I> for a <CODE>TAG</CODE> then all
|
|
|
5353 |
other <I>make_id_tagdec</I> for the same <CODE>TAG</CODE> will specify
|
|
|
5354 |
the same <CODE>SHAPE</CODE> and there will be no <I>make_var_tagdec</I>
|
|
|
5355 |
or <I>common_tagdec</I> for the <CODE>TAG</CODE>.
|
|
|
5356 |
<P>
|
|
|
5357 |
If two <I>make_id_tagdecs</I> specify the same tag and both have
|
|
|
5358 |
<I>signatures</I> present, the strings will be identical. Possible
|
|
|
5359 |
uses of this signature argument are outlined in
|
|
|
5360 |
<A HREF="spec10.html#72">section 7.28</A>.
|
|
|
5361 |
<P>
|
|
|
5362 |
<P>
|
|
|
5363 |
|
|
|
5364 |
<H3>5.37.2. <A NAME=M329>make_var_tagdec</A></H3>
|
|
|
5365 |
<B>Encoding number</B>: 2<P>
|
|
|
5366 |
<PRE>
|
|
|
5367 |
<I>t_intro</I>: TDFINT
|
|
|
5368 |
<I>acc</I>: OPTION(ACCESS)
|
|
|
5369 |
<I>signature</I>: OPTION(STRING)
|
|
|
5370 |
<I>x</I>: SHAPE
|
|
|
5371 |
-> TAGDEC
|
|
|
5372 |
</PRE>
|
|
|
5373 |
A <CODE>TAGDEC</CODE> announcing that the <CODE>TAG</CODE>
|
|
|
5374 |
<I>t_intro</I> identifies an <CODE>EXP</CODE> of <CODE>SHAPE POINTER</CODE>(<I>alignment
|
|
|
5375 |
</I>(<I>x</I>)) is constructed.
|
|
|
5376 |
<P>
|
|
|
5377 |
<I>acc</I> specifies the <CODE>ACCESS</CODE> properties of the
|
|
|
5378 |
<CODE>TAG</CODE>.
|
|
|
5379 |
<P>
|
|
|
5380 |
If there is a <I>make_var_tagdec</I> for a <CODE>TAG</CODE> then all
|
|
|
5381 |
other <I>make_var_tagdec</I>s for the same <CODE>TAG</CODE> will specify
|
|
|
5382 |
<CODE>SHAPE</CODE>s with identical <CODE>ALIGNMENT</CODE> and there
|
|
|
5383 |
will be no <I>make_id_tagdec</I> or <I>common_tagdec</I> for the
|
|
|
5384 |
<CODE>TAG</CODE>.
|
|
|
5385 |
<P>
|
|
|
5386 |
If two <I>make_var_tagdec</I>s specify the same tag and both have
|
|
|
5387 |
<I>signature</I> present, the strings will be identical. Possible
|
|
|
5388 |
uses of this signature argument are outlined in
|
|
|
5389 |
<A HREF="spec10.html#72">section 7.28</A>.
|
|
|
5390 |
<P>
|
|
|
5391 |
|
|
|
5392 |
<H3>5.37.3. <A NAME=M331>common_tagdec</A></H3>
|
|
|
5393 |
<B>Encoding number</B>: 3<P>
|
|
|
5394 |
<PRE>
|
|
|
5395 |
<I>t_intro</I>: TDFINT
|
|
|
5396 |
<I>acc</I>: OPTION(ACCESS)
|
|
|
5397 |
<I>signature</I>: OPTION(STRING)
|
|
|
5398 |
<I>x</I>: SHAPE
|
|
|
5399 |
-> TAGDEC
|
|
|
5400 |
</PRE>
|
|
|
5401 |
A <CODE>TAGDEC</CODE> announcing that the <CODE>TAG</CODE>
|
|
|
5402 |
<I>t_intro</I> identifies an <CODE>EXP</CODE> of <CODE>SHAPE POINTER</CODE>(<I>alignment
|
|
|
5403 |
</I>(<I>x</I>)) is constructed.
|
|
|
5404 |
<P>
|
|
|
5405 |
<I>acc</I> specifies the <CODE>ACCESS</CODE> properties of the
|
|
|
5406 |
<CODE>TAG</CODE>.
|
|
|
5407 |
<P>
|
|
|
5408 |
If there is a <I>common_tagdec</I> for a <CODE>TAG</CODE> then there
|
|
|
5409 |
will be no <I>make_id_tagdec</I> or <I>make_var_tagdec</I> for that
|
|
|
5410 |
<CODE>TAG</CODE>. If there is more than one <I>common_tagdec</I> for
|
|
|
5411 |
a <CODE>TAG</CODE> the one having the maximum <CODE>SHAPE</CODE> shall
|
|
|
5412 |
be taken to apply for the <CODE>CAPSULE</CODE>. Each pair of such
|
|
|
5413 |
<CODE>SHAPE</CODE>s will have a maximum. The maximum of two
|
|
|
5414 |
<CODE>SHAPE</CODE>s, <I>a</I> and <I>b</I>, is defined as follows:
|
|
|
5415 |
<UL>
|
|
|
5416 |
<LI>If the <I>a</I> is equal to <I>b</I> the maximum is <I>a</I>.
|
|
|
5417 |
<LI>If <I>a</I> and <I>b</I> are <CODE>COMPOUND</CODE>(<I>x</I>) and
|
|
|
5418 |
<CODE>COMPOUND</CODE>(<I>y</I>) respectively and <I>a</I> is an initial
|
|
|
5419 |
segment of <I>b</I>, then <I>b</I> is the maximum. Similarly if <I>b</I>
|
|
|
5420 |
is an initial segment of <I>a</I> then <I>a</I> is the maximum.
|
|
|
5421 |
<LI>If <I>a</I> and <I>b</I> are <CODE>NOF</CODE>(<I>n</I>, <I>x</I>)
|
|
|
5422 |
and <CODE>NOF</CODE>(<I>m</I>, <I>x</I>) respectively and <I>n</I>
|
|
|
5423 |
is less than or equal to <I>m</I>, then <I>b</I> is the maximum. Similarly
|
|
|
5424 |
if <I>m</I> is less than or equal to <I>n</I> then <I>a</I> is the
|
|
|
5425 |
maximum.
|
|
|
5426 |
<LI>Otherwise <I>a</I> and <I>b</I> have no maximum.
|
|
|
5427 |
</UL>
|
|
|
5428 |
If two <I>common_tagdecs</I> specify the same tag and both have
|
|
|
5429 |
<I>signatures</I> present, the strings will be identical. Possible
|
|
|
5430 |
uses of this signature argument are outlined in
|
|
|
5431 |
<A HREF="spec10.html#72">section 7.28</A>.
|
|
|
5432 |
<P>
|
|
|
5433 |
<P>
|
|
|
5434 |
|
|
|
5435 |
<HR>
|
|
|
5436 |
<H2>5.38. <A NAME=M332>TAGDEC_PROPS</A></H2>
|
|
|
5437 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5438 |
<B>Is coding extendable</B>: no<BR>
|
|
|
5439 |
<B>Unit identification</B>: <I>tagdec</I><P>
|
|
|
5440 |
|
|
|
5441 |
<H3>5.38.1. <A NAME=M333>make_tagdecs</A></H3>
|
|
|
5442 |
<B>Encoding number</B>: 0<P>
|
|
|
5443 |
<PRE>
|
|
|
5444 |
<I>no_labels</I>: TDFINT
|
|
|
5445 |
<I>tds</I>: SLIST(TAGDEC)
|
|
|
5446 |
-> TAGDEC_PROPS
|
|
|
5447 |
</PRE>
|
|
|
5448 |
<I>no_labels</I> is the number of local <CODE>LABEL</CODE>s used in
|
|
|
5449 |
<I>tds</I>. <I>tds</I> is a list of <CODE>TAGDEC</CODE>s which declare
|
|
|
5450 |
the <CODE>SHAPE</CODE>s associated with <CODE>TAG</CODE>s.
|
|
|
5451 |
<P>
|
|
|
5452 |
|
|
|
5453 |
<HR>
|
|
|
5454 |
<H2>5.39. <A NAME=M334>TAGDEF</A></H2>
|
|
|
5455 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
5456 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5457 |
A value of <CODE>SORT TAGDEF</CODE> gives the definition of a <CODE>TAG</CODE>
|
|
|
5458 |
for incorporation into a <CODE>TAGDEF_PROPS</CODE>.
|
|
|
5459 |
<P>
|
|
|
5460 |
|
|
|
5461 |
<H3>5.39.1. <A NAME=M335>make_id_tagdef</A></H3>
|
|
|
5462 |
<!-- BREAK 1 -->
|
|
|
5463 |
<B>Encoding number</B>: 1<P>
|
|
|
5464 |
<PRE>
|
|
|
5465 |
<I>t</I>: TDFINT
|
|
|
5466 |
<I>signature</I>: OPTION(STRING)
|
|
|
5467 |
<I>e</I>: EXP <I>x</I>
|
|
|
5468 |
-> TAGDEF
|
|
|
5469 |
</PRE>
|
|
|
5470 |
<I>make_id_tagdef</I> produces a <CODE>TAGDEF</CODE> defining the
|
|
|
5471 |
<CODE>TAG</CODE> <I>x</I> constructed from the <CODE>TDFINT</CODE>,
|
|
|
5472 |
<I>t</I>. This <CODE>TAG</CODE> is defined to stand for the value
|
|
|
5473 |
delivered by <I>e</I>.
|
|
|
5474 |
<P>
|
|
|
5475 |
<I>e</I> will be a constant which can be evaluated at load_time or
|
|
|
5476 |
<I>e</I> will be some <I>initial_value</I>(E) (see <A HREF="#M125">section
|
|
|
5477 |
5.16.48</A>).
|
|
|
5478 |
<P>
|
|
|
5479 |
<I>t</I> will be declared in the <CODE>CAPSULE</CODE> using
|
|
|
5480 |
<I>make_id_tagdec</I>. If both the <I>make_id_tagdec</I> and
|
|
|
5481 |
<I>make_id_tagdef</I> have <I>signatures</I> present, the strings
|
|
|
5482 |
will be identical.
|
|
|
5483 |
<P>
|
|
|
5484 |
If <I>x</I> is <CODE>PROC</CODE> and the <CODE>TAG</CODE> represented
|
|
|
5485 |
by <I>t</I> is named externally via a <CODE>CAPSULE_LINK</CODE>, e
|
|
|
5486 |
will be some <I>make_proc</I> or <I>make_general_proc</I>.
|
|
|
5487 |
<P>
|
|
|
5488 |
There will not be more than one <CODE>TAGDEF</CODE> defining <I>t</I>
|
|
|
5489 |
in a <CODE>CAPSULE</CODE>.
|
|
|
5490 |
<P>
|
|
|
5491 |
|
|
|
5492 |
<H3>5.39.2. <A NAME=M336>make_var_tagdef</A></H3>
|
|
|
5493 |
<!-- BREAK 1 -->
|
|
|
5494 |
<B>Encoding number</B>: 2<P>
|
|
|
5495 |
<PRE>
|
|
|
5496 |
<I>t</I>: TDFINT
|
|
|
5497 |
<I>opt_access</I>: OPTION(ACCESS)
|
|
|
5498 |
<I>signature</I>: OPTION(STRING)
|
|
|
5499 |
<I>e</I>: EXP <I>x</I>
|
|
|
5500 |
-> TAGDEF
|
|
|
5501 |
</PRE>
|
|
|
5502 |
<I>make_var_tagdef</I> produces a <CODE>TAGDEF</CODE> defining the
|
|
|
5503 |
<CODE>TAG POINTER</CODE>(<I>alignment(x)</I>) constructed from the
|
|
|
5504 |
<CODE>TDFINT</CODE>, <I>t</I>. This <CODE>TAG</CODE> stands for a
|
|
|
5505 |
variable which is initialised with the value delivered by <I>e</I>.
|
|
|
5506 |
The <CODE>TAG</CODE> is bound to an original pointer which has the
|
|
|
5507 |
evaluation of the program as its lifetime.
|
|
|
5508 |
<P>
|
|
|
5509 |
If <I>opt_access</I> contains <I>visible</I>, the meaning is that
|
|
|
5510 |
the variable may be used by agents external to the capsule, and so
|
|
|
5511 |
it must not be optimised away. If it contains constant, the initialising
|
|
|
5512 |
value will remain in it throughout the program.
|
|
|
5513 |
<P>
|
|
|
5514 |
<I>e</I> will be a constant which can be evaluated at load_time or
|
|
|
5515 |
<I>e</I> will be some <I>initial_value</I>(<I>e1</I>) (see
|
|
|
5516 |
<A HREF="#M125">section 5.16.48</A>).
|
|
|
5517 |
<P>
|
|
|
5518 |
<I>t</I> will be declared in the <CODE>CAPSULE</CODE> using
|
|
|
5519 |
<I>make_var_tagdec</I>. If both the <I>make_var_tagdec</I> and
|
|
|
5520 |
<I>make_var_tagdef</I> have <I>signatures</I> present, the strings
|
|
|
5521 |
will be identical.
|
|
|
5522 |
<P>
|
|
|
5523 |
<P>
|
|
|
5524 |
There will not be more than one <CODE>TAGDEF</CODE> defining <I>t</I>
|
|
|
5525 |
in a <CODE>CAPSULE</CODE>.
|
|
|
5526 |
<P>
|
|
|
5527 |
|
|
|
5528 |
<H3>5.39.3. <A NAME=M338>common_tagdef</A></H3>
|
|
|
5529 |
<!-- BREAK 1 -->
|
|
|
5530 |
<B>Encoding number</B>: 3<P>
|
|
|
5531 |
<PRE>
|
|
|
5532 |
<I>t</I>: TDFINT
|
|
|
5533 |
<I>opt_access</I>: OPTION(ACCESS)
|
|
|
5534 |
<I>signature</I>: OPTION(STRING)
|
|
|
5535 |
<I>e</I>: EXP <I>x</I>
|
|
|
5536 |
-> TAGDEF
|
|
|
5537 |
</PRE>
|
|
|
5538 |
<I>common_tagdef</I> produces a <CODE>TAGDEF</CODE> defining the
|
|
|
5539 |
<CODE>TAG</CODE> <CODE>POINTER</CODE>(<I>alignment(x)</I>) constructed
|
|
|
5540 |
from the <CODE>TDFINT</CODE>, <I>t</I>. This <CODE>TAG</CODE> stands
|
|
|
5541 |
for a variable which is initialised with the value delivered by <I>e</I>.
|
|
|
5542 |
The <CODE>TAG</CODE> is bound to an original pointer which has the
|
|
|
5543 |
evaluation of the program as its lifetime.
|
|
|
5544 |
<P>
|
|
|
5545 |
If <I>opt_access</I> contains <I>visible</I>, the meaning is that
|
|
|
5546 |
the variable may be used by agents external to the capsule, and so
|
|
|
5547 |
it must not be optimised away. If it contains constant, the initialising
|
|
|
5548 |
value will remain in it throughout the program.
|
|
|
5549 |
<P>
|
|
|
5550 |
<I>e</I> will be a constant evaluable at load_time or <I>e</I> will
|
|
|
5551 |
be some <I>initial_value</I>(E) (see <A HREF="#M125">section 5.16.48
|
|
|
5552 |
</A>).
|
|
|
5553 |
<P>
|
|
|
5554 |
<I>t</I> will be declared in the <CODE>CAPSULE</CODE> using
|
|
|
5555 |
<I>common_tagdec</I>.If both the <I>common_tagdec</I> and<BR>
|
|
|
5556 |
<I>common_tagdef</I> have <I>signatures</I> present, the strings<BR>
|
|
|
5557 |
will be identical. Let the maximum <CODE>SHAPE</CODE> of these (see
|
|
|
5558 |
<A HREF="#M331">common_tagdec</A>) be <I>s</I>.
|
|
|
5559 |
<P>
|
|
|
5560 |
There may be any number of <I>common_tagdef</I> definitions for <I>t</I>
|
|
|
5561 |
in a <CODE>CAPSULE</CODE>. Of the <I>e</I> parameters of these, one
|
|
|
5562 |
will be a maximum. This maximum definition is chosen as the definition
|
|
|
5563 |
of <I>t</I>. Its value of <I>e</I> will have <CODE>SHAPE</CODE> <I>s</I>.
|
|
|
5564 |
<P>
|
|
|
5565 |
The maximum of two <I>common_tagdef</I> <CODE>EXP</CODE>s, <I>a</I>
|
|
|
5566 |
and <I>b</I>, is defined as follows:
|
|
|
5567 |
<UL>
|
|
|
5568 |
<LI>If <I>a</I> has the form <I>make_value</I>(<I>s</I>), <I>b</I>
|
|
|
5569 |
is the maximum.
|
|
|
5570 |
<LI>If <I>b</I> has the form <I>make_value</I>(<I>s</I>), <I>a</I>
|
|
|
5571 |
is the maximum.
|
|
|
5572 |
<LI>If <I>a</I> and <I>b</I> have <CODE>SHAPE COMPOUND</CODE>(<I>x</I>)
|
|
|
5573 |
and <CODE>COMPOUND</CODE>(<I>y</I>) respectively and the value produced
|
|
|
5574 |
by <I>a</I> is an initial segment of the value produced by <I>b</I>,
|
|
|
5575 |
then <I>b</I> is the maximum. Similarly if <I>b</I> is an initial
|
|
|
5576 |
segment of <I>a</I> then <I>a</I> is the maximum.
|
|
|
5577 |
<LI>If <I>a</I> and <I>b</I> have <CODE>SHAPE NOF</CODE>(<I>n</I>,
|
|
|
5578 |
<I>x</I>) and <CODE>NOF</CODE>(<I>m</I>, <I>x</I>) respectively and
|
|
|
5579 |
the value produced by <I>a</I> is an initial segment of the value
|
|
|
5580 |
produced by
|
|
|
5581 |
<I>b</I>, then <I>b</I> is the maximum. Similarly if <I>b</I> is an
|
|
|
5582 |
initial segment of <I>a</I> then <I>a</I> is the maximum.
|
|
|
5583 |
<LI>If the value produced by <I>a</I> is equal to the value produced
|
|
|
5584 |
by <I>b</I> the maximum is <I>a</I>.
|
|
|
5585 |
<LI>Otherwise <I>a</I> and <I>b</I> have no maximum.
|
|
|
5586 |
</UL>
|
|
|
5587 |
|
|
|
5588 |
<HR>
|
|
|
5589 |
<H2>5.40. <A NAME=M340>TAGDEF_PROPS</A></H2>
|
|
|
5590 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5591 |
<B>Is coding extendable</B>: no<BR>
|
|
|
5592 |
<B>Unit identification</B>: <I>tagdef</I><P>
|
|
|
5593 |
|
|
|
5594 |
<H3>5.40.1. <A NAME=M341>make_tagdefs</A></H3>
|
|
|
5595 |
<B>Encoding number</B>: 0<P>
|
|
|
5596 |
<PRE>
|
|
|
5597 |
<I>no_labels</I>: TDFINT
|
|
|
5598 |
<I>tds</I>: SLIST(TAGDEF)
|
|
|
5599 |
-> TAGDEF_PROPS
|
|
|
5600 |
</PRE>
|
|
|
5601 |
<I>no_labels</I> is the number of local <CODE>LABEL</CODE>s used in
|
|
|
5602 |
<I>tds</I>. <I>tds</I> is a list of <CODE>TAGDEF</CODE>s which give
|
|
|
5603 |
the <CODE>EXP</CODE>s which are the definitions of values associated
|
|
|
5604 |
with <CODE>TAG</CODE>s.
|
|
|
5605 |
<P>
|
|
|
5606 |
|
|
|
5607 |
<HR>
|
|
|
5608 |
<H2>5.41. <A NAME=M342>TAGSHACC</A></H2>
|
|
|
5609 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5610 |
<B>Is coding extendable</B>: no<P>
|
|
|
5611 |
|
|
|
5612 |
<H3>5.41.1. <A NAME=M343>make_tagshacc</A></H3>
|
|
|
5613 |
<B>Encoding number</B>: 0<P>
|
|
|
5614 |
<PRE>
|
|
|
5615 |
<I>sha</I>: SHAPE
|
|
|
5616 |
<I>opt_access</I>: OPTION(ACCESS)
|
|
|
5617 |
<I>tg_intro</I>: TAG
|
|
|
5618 |
-> TAGSHACC
|
|
|
5619 |
</PRE>
|
|
|
5620 |
This is an auxiliary construction to make the elements of
|
|
|
5621 |
<I>params_intro</I> in <I>make_proc</I>.
|
|
|
5622 |
<P>
|
|
|
5623 |
|
|
|
5624 |
<HR>
|
|
|
5625 |
<H2>5.42. <A NAME=M344>TDFBOOL</A></H2>
|
|
|
5626 |
A <CODE>TDFBOOL</CODE> is the TDF encoding of a boolean. See
|
|
|
5627 |
<A HREF="spec11.html#4">Fundamental encoding</A>.
|
|
|
5628 |
<P>
|
|
|
5629 |
|
|
|
5630 |
<HR>
|
|
|
5631 |
<H2>5.43. <A NAME=M345>TDFIDENT</A></H2>
|
|
|
5632 |
A <CODE>TDFIDENT</CODE>(<I>k</I>, <I>n</I>) encodes a sequence of
|
|
|
5633 |
<I>n</I> unsigned integers of size <I>k</I> bits. <I>k</I> will be
|
|
|
5634 |
a multiple of 8. See <A HREF="spec11.html#4">Fundamental encoding</A>.
|
|
|
5635 |
<P>
|
|
|
5636 |
This construction will not be used inside a <CODE>BITSTREAM</CODE>.
|
|
|
5637 |
<P>
|
|
|
5638 |
|
|
|
5639 |
<HR>
|
|
|
5640 |
<H2>5.44. <A NAME=M346>TDFINT</A></H2>
|
|
|
5641 |
A <CODE>TDFINT</CODE> is the TDF encoding of an unbounded unsigned
|
|
|
5642 |
integer constant. See <A HREF="spec11.html#4">Fundamental encoding</A>.
|
|
|
5643 |
<P>
|
|
|
5644 |
|
|
|
5645 |
<HR>
|
|
|
5646 |
<H2>5.45. <A NAME=M347>TDFSTRING</A></H2>
|
|
|
5647 |
A <CODE>TDFSTRING</CODE>(<I>k</I>, <I>n</I>) encodes a sequence of
|
|
|
5648 |
<I>n</I> unsigned integers of size <I>k</I> bits. See <A HREF="spec11.html#4">Fundamental
|
|
|
5649 |
encoding</A>.
|
|
|
5650 |
<P>
|
|
|
5651 |
|
|
|
5652 |
<HR>
|
|
|
5653 |
<H2>5.46. <A NAME=M348>TOKDEC</A></H2>
|
|
|
5654 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
5655 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5656 |
A <CODE>TOKDEC</CODE> declares a <CODE>TOKEN</CODE> for incorporation
|
|
|
5657 |
into a <CODE>UNIT</CODE>.
|
|
|
5658 |
<P>
|
|
|
5659 |
|
|
|
5660 |
<H3>5.46.1. <A NAME=M349>make_tokdec</A></H3>
|
|
|
5661 |
<B>Encoding number</B>: 1<P>
|
|
|
5662 |
<PRE>
|
|
|
5663 |
<I>tok</I>: TDFINT
|
|
|
5664 |
<I>signature</I>: OPTION(STRING)
|
|
|
5665 |
<I>s</I>: SORTNAME
|
|
|
5666 |
-> TOKDEC
|
|
|
5667 |
</PRE>
|
|
|
5668 |
The sort of the token <I>tok</I> is declared to be <I>s</I>. Note
|
|
|
5669 |
that
|
|
|
5670 |
<I>s</I> will always be a token <CODE>SORT</CODE>, with a list of
|
|
|
5671 |
parameter <CODE>SORT</CODE>s (possible empty) and a result
|
|
|
5672 |
<CODE>SORT</CODE>.
|
|
|
5673 |
<P>
|
|
|
5674 |
If <I>signature</I> is present, it will be produced by <I>make_string</I>.
|
|
|
5675 |
<P>
|
|
|
5676 |
If two <I>make_tokdecs</I> specify the same token and both have
|
|
|
5677 |
<I>signatures</I> present, the strings will be identical. Possible
|
|
|
5678 |
uses of this signature argument are outlined in
|
|
|
5679 |
<A HREF="spec10.html#72">section 7.28</A>.
|
|
|
5680 |
<P>
|
|
|
5681 |
<P>
|
|
|
5682 |
|
|
|
5683 |
<HR>
|
|
|
5684 |
<H2>5.47. <A NAME=M350>TOKDEC_PROPS</A></H2>
|
|
|
5685 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5686 |
<B>Is coding extendable</B>: no<BR>
|
|
|
5687 |
<B>Unit identification</B>: <I>tokdec</I><P>
|
|
|
5688 |
|
|
|
5689 |
<H3>5.47.1. <A NAME=M351>make_tokdecs</A></H3>
|
|
|
5690 |
<B>Encoding number</B>: 0<P>
|
|
|
5691 |
<PRE>
|
|
|
5692 |
<I>tds</I>: SLIST(TOKDEC)
|
|
|
5693 |
-> TOKDEC_PROPS
|
|
|
5694 |
</PRE>
|
|
|
5695 |
<I>tds</I> is a list of <CODE>TOKDEC</CODE>s which gives the sorts
|
|
|
5696 |
associated with <CODE>TOKEN</CODE>s.
|
|
|
5697 |
<P>
|
|
|
5698 |
|
|
|
5699 |
<HR>
|
|
|
5700 |
<H2>5.48. <A NAME=M352>TOKDEF</A></H2>
|
|
|
5701 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
5702 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5703 |
A <CODE>TOKDEF</CODE> gives the definition of a <CODE>TOKEN</CODE>
|
|
|
5704 |
for incorporation into a <CODE>TOKDEF_PROPS</CODE>.
|
|
|
5705 |
<P>
|
|
|
5706 |
|
|
|
5707 |
<H3>5.48.1. <A NAME=M353>make_tokdef</A></H3>
|
|
|
5708 |
<B>Encoding number</B>: 1<P>
|
|
|
5709 |
<PRE>
|
|
|
5710 |
<I>tok</I>: TDFINT
|
|
|
5711 |
<I>signature</I>: OPTION(STRING)
|
|
|
5712 |
<I>def</I>: BITSTREAM TOKEN_DEFN
|
|
|
5713 |
-> TOKDEF
|
|
|
5714 |
</PRE>
|
|
|
5715 |
A <CODE>TOKDEF</CODE> is constructed which defines the <CODE>TOKEN</CODE>
|
|
|
5716 |
<I>tok</I> to stand for the fragment of TDF, <I>body</I>, which may
|
|
|
5717 |
be of any <CODE>SORT</CODE> with a <CODE>SORTNAME</CODE>, except for
|
|
|
5718 |
<I>token</I>. The <CODE>SORT</CODE> of the result, <I>result_sort</I>,
|
|
|
5719 |
is given by the first component of the <CODE>BITSTREAM</CODE>. See
|
|
|
5720 |
<A HREF="#M362">token_definition</A>.
|
|
|
5721 |
<P>
|
|
|
5722 |
If <I>signature</I> is present, it will be produced by <I>make_string</I>.
|
|
|
5723 |
<P>
|
|
|
5724 |
<I>tok</I> may have been introduced by a <I>make_tokdec</I>. If both
|
|
|
5725 |
the <I>make_tokdec</I> and <I>make_tokdef</I> have <I>signatures</I>
|
|
|
5726 |
present, the strings will be identical.
|
|
|
5727 |
<P>
|
|
|
5728 |
At the application of this <CODE>TOKEN</CODE> actual pieces of TDF
|
|
|
5729 |
having <CODE>SORT</CODE> <I>sn</I>[<I>i</I>] are supplied to correspond
|
|
|
5730 |
to the <I>tk</I>[<I>i</I>]. The application denotes the piece of TDF
|
|
|
5731 |
obtained by substituting these actual parameters for the corresponding
|
|
|
5732 |
<CODE>TOKEN</CODE>s within <I>body</I>.
|
|
|
5733 |
<P>
|
|
|
5734 |
|
|
|
5735 |
<HR>
|
|
|
5736 |
<H2>5.49. <A NAME=M354>TOKDEF_PROPS</A></H2>
|
|
|
5737 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5738 |
<B>Is coding extendable</B>: no<BR>
|
|
|
5739 |
<B>Unit identification</B>: <I>tokdef</I><P>
|
|
|
5740 |
|
|
|
5741 |
<H3>5.49.1. <A NAME=M355>make_tokdefs</A></H3>
|
|
|
5742 |
<B>Encoding number</B>: 0<P>
|
|
|
5743 |
<PRE>
|
|
|
5744 |
<I>no_labels</I>: TDFINT
|
|
|
5745 |
<I>tds</I>: SLIST(TOKDEF)
|
|
|
5746 |
-> TOKDEF_PROPS
|
|
|
5747 |
</PRE>
|
|
|
5748 |
<I>no_labels</I> is the number of local <CODE>LABEL</CODE>s used in
|
|
|
5749 |
<I>tds</I>. <I>tds</I> is a list of <CODE>TOKDEF</CODE>s which gives
|
|
|
5750 |
the definitions associated with <CODE>TOKEN</CODE>s.
|
|
|
5751 |
<P>
|
|
|
5752 |
|
|
|
5753 |
<HR>
|
|
|
5754 |
<H2>5.50. <A NAME=M356>TOKEN</A></H2>
|
|
|
5755 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
5756 |
<B>Is coding extendable</B>: yes<BR>
|
|
|
5757 |
<B>Linkable entity identification</B>: <I>token</I><P>
|
|
|
5758 |
These are used to stand for functions evaluated at installation time.
|
|
|
5759 |
They are represented by <CODE>TDFINT</CODE>s.
|
|
|
5760 |
<P>
|
|
|
5761 |
|
|
|
5762 |
<H3>5.50.1. <A NAME=M357>token_apply_token</A></H3>
|
|
|
5763 |
<B>Encoding number</B>: 1<P>
|
|
|
5764 |
<PRE>
|
|
|
5765 |
<I>token_value</I>: TOKEN
|
|
|
5766 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
5767 |
-> TOKEN
|
|
|
5768 |
</PRE>
|
|
|
5769 |
The token is applied to the arguments to give a <CODE>TOKEN</CODE>.
|
|
|
5770 |
<P>
|
|
|
5771 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
5772 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
5773 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
5774 |
<P>
|
|
|
5775 |
|
|
|
5776 |
<H3>5.50.2. <A NAME=M358>make_tok</A></H3>
|
|
|
5777 |
<B>Encoding number</B>: 2<P>
|
|
|
5778 |
<PRE>
|
|
|
5779 |
<I>tokno</I>: TDFINT
|
|
|
5780 |
-> TOKEN
|
|
|
5781 |
</PRE>
|
|
|
5782 |
<I>make_tok</I> constructs a <CODE>TOKEN</CODE> identified by <I>tokno</I>.
|
|
|
5783 |
<P>
|
|
|
5784 |
|
|
|
5785 |
<H3>5.50.3. <A NAME=M359>use_tokdef</A></H3>
|
|
|
5786 |
<B>Encoding number</B>: 3<P>
|
|
|
5787 |
<PRE>
|
|
|
5788 |
<I>tdef</I>: BITSTREAM TOKEN_DEFN
|
|
|
5789 |
-> TOKEN
|
|
|
5790 |
</PRE>
|
|
|
5791 |
<I>tdef</I> is used to supply the definition, as in <I>make_tokdef</I>.
|
|
|
5792 |
Note that <CODE>TOKEN</CODE>s are only used in <I>x_apply_token</I>
|
|
|
5793 |
constructions.
|
|
|
5794 |
<P>
|
|
|
5795 |
|
|
|
5796 |
<HR>
|
|
|
5797 |
<H2>5.51. <A NAME=M360>TOKEN_DEFN</A></H2>
|
|
|
5798 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
5799 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5800 |
An auxiliary <CODE>SORT</CODE> used in <I>make_tokdef</I> and
|
|
|
5801 |
<I>use_tokdef</I>.
|
|
|
5802 |
<P>
|
|
|
5803 |
|
|
|
5804 |
<H3>5.51.1. <A NAME=M362>token_definition</A></H3>
|
|
|
5805 |
<B>Encoding number</B>: 1<P>
|
|
|
5806 |
<PRE>
|
|
|
5807 |
<I>result_sort</I>: SORTNAME
|
|
|
5808 |
<I>tok_params</I>: LIST(TOKFORMALS)
|
|
|
5809 |
<I>body</I>: <I>result_sort</I>
|
|
|
5810 |
-> TOKEN_DEFN
|
|
|
5811 |
</PRE>
|
|
|
5812 |
Makes a token definition. <I>result_sort</I> is the <CODE>SORT</CODE>
|
|
|
5813 |
of body. <I>tok_params</I> is a list of formal <CODE>TOKEN</CODE>s
|
|
|
5814 |
and their <CODE>SORT</CODE>s. <I>body</I> is the definition, which
|
|
|
5815 |
can use the formal <CODE>TOKEN</CODE>s defined in <I>tok_params</I>.
|
|
|
5816 |
<P>
|
|
|
5817 |
The effect of applying the definition of a <CODE>TOKEN</CODE> is as
|
|
|
5818 |
if the following sequence was obeyed.
|
|
|
5819 |
<P>
|
|
|
5820 |
First, the actual parameters (if any) are expanded to produce expressions
|
|
|
5821 |
of the appropriate <CODE>SORT</CODE>s. During this expansion all token
|
|
|
5822 |
applications in the actual parameters are expanded.
|
|
|
5823 |
<P>
|
|
|
5824 |
Second, the definition is copied, making fresh <CODE>TAG</CODE>s and
|
|
|
5825 |
<CODE>LABEL</CODE>s where these are introduced in <I>identify</I>,
|
|
|
5826 |
<I>variable</I>, <I>labelled</I>, <I>conditional</I>, <I>make_proc,
|
|
|
5827 |
make_general_proc</I> and <I>repeat</I> constructions. Any other
|
|
|
5828 |
<CODE>TAG</CODE>s or <CODE>LABEL</CODE>s used in <I>body</I> will
|
|
|
5829 |
be provided by the context (see below) of the <CODE>TOKEN_DEFN</CODE>
|
|
|
5830 |
or by the expansions of the actual parameters.
|
|
|
5831 |
<P>
|
|
|
5832 |
Third, the actual parameter expressions are substituted for the formal
|
|
|
5833 |
parameter tokens in <I>tok_params</I> to give the final result.
|
|
|
5834 |
<P>
|
|
|
5835 |
The context of a <CODE>TOKEN_DEFN</CODE> is the set of names (<CODE>TOKEN</CODE>s,
|
|
|
5836 |
<CODE>TAG</CODE>s, <CODE>LABEL</CODE>s,
|
|
|
5837 |
<CODE>AL_TAG</CODE>s etc.) "in scope" at the site of the
|
|
|
5838 |
<CODE>TOKEN_DEFN</CODE>.
|
|
|
5839 |
<P>
|
|
|
5840 |
Thus, in a <I>make_tokdef</I>, the context consists of the set of
|
|
|
5841 |
<CODE>TOKEN</CODE>s defined in its tokdef <CODE>UNIT</CODE>, together
|
|
|
5842 |
with the set of linkable entities defined by the <I>make_links</I>
|
|
|
5843 |
of that <CODE>UNIT</CODE>. Note that this does not include
|
|
|
5844 |
<CODE>LABEL</CODE>s and the only <CODE>TAG</CODE>s included are "global"
|
|
|
5845 |
ones.
|
|
|
5846 |
<P>
|
|
|
5847 |
In a <I>use_tokdef</I>, the context may be wider, since the site of
|
|
|
5848 |
the
|
|
|
5849 |
<CODE>TOKEN_DEFN</CODE> need not be in a tokdef <CODE>UNIT</CODE>;
|
|
|
5850 |
it may be an actual parameter of a token application. If this happens
|
|
|
5851 |
to be within an EXP, there may be <CODE>TAG</CODE>s or <CODE>LABEL</CODE>s
|
|
|
5852 |
locally within scope; these will be in the context of the
|
|
|
5853 |
<CODE>TOKEN_DEFN</CODE>, together with the global names of the enclosing
|
|
|
5854 |
UNIT as before.
|
|
|
5855 |
<P>
|
|
|
5856 |
<I>Previous versions of the specification limited token definitions
|
|
|
5857 |
to be non-recursive. There is no intrinsic reason for the limitation
|
|
|
5858 |
on recursive <CODE>TOKEN</CODE>s. Since the UNIT structure implies
|
|
|
5859 |
different namespaces, there is very little implementation advantage
|
|
|
5860 |
to be gained from retaining the limitation.</I>
|
|
|
5861 |
<P>
|
|
|
5862 |
|
|
|
5863 |
<HR>
|
|
|
5864 |
<H2>5.52. <A NAME=M363>TOKFORMALS</A></H2>
|
|
|
5865 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
5866 |
<B>Is coding extendable</B>: no<P>
|
|
|
5867 |
|
|
|
5868 |
<H3>5.52.1. <A NAME=M364>make_tokformals</A></H3>
|
|
|
5869 |
<B>Encoding number</B>: 0<P>
|
|
|
5870 |
<PRE>
|
|
|
5871 |
<I>sn</I>: SORTNAME
|
|
|
5872 |
<I>tk</I>: TDFINT
|
|
|
5873 |
-> TOKFORMALS
|
|
|
5874 |
</PRE>
|
|
|
5875 |
An auxiliary construction to make up the elements of the lists in
|
|
|
5876 |
<I>token_definition</I>.
|
|
|
5877 |
<P>
|
|
|
5878 |
|
|
|
5879 |
<HR>
|
|
|
5880 |
<H2>5.53. <A NAME=M365>TRANSFER_MODE</A></H2>
|
|
|
5881 |
<B>Number of encoding bits</B>: 3<BR>
|
|
|
5882 |
<B>Is coding extendable</B>: yes<P>
|
|
|
5883 |
A <CODE>TRANSFER_MODE</CODE> controls the operation of
|
|
|
5884 |
<I>assign_with_mode</I>, <I>contents_with_mode</I> and <I>move_some</I>.
|
|
|
5885 |
<P>
|
|
|
5886 |
A <CODE>TRANSFER_MODE</CODE> acts like a set of the values <I>overlap,
|
|
|
5887 |
trap_on_nil, complete</I> and <I>volatile</I>. The
|
|
|
5888 |
<CODE>TRANSFER_MODE</CODE> <I>standard_transfer_mode</I> acts like
|
|
|
5889 |
the empty set. <I>add_modes</I> acts like set union.
|
|
|
5890 |
<P>
|
|
|
5891 |
|
|
|
5892 |
<H3>5.53.1. <A NAME=M366>transfer_mode_apply_token</A></H3>
|
|
|
5893 |
<B>Encoding number</B>: 1<P>
|
|
|
5894 |
<PRE>
|
|
|
5895 |
<I>token_value</I>: TOKEN
|
|
|
5896 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
5897 |
-> TRANSFER_MODE
|
|
|
5898 |
</PRE>
|
|
|
5899 |
The token is applied to the arguments encoded in the <CODE>BITSTREAM</CODE>
|
|
|
5900 |
<I>token_args</I> to give a <CODE>TRANSFER_MODE</CODE>.
|
|
|
5901 |
<P>
|
|
|
5902 |
The notation <I>param_sorts(token_value)</I> is intended to mean the
|
|
|
5903 |
following. The token definition or token declaration for
|
|
|
5904 |
<I>token_value</I> gives the <CODE>SORT</CODE>s of its arguments in
|
|
|
5905 |
the
|
|
|
5906 |
<CODE>SORTNAME</CODE> component. The <CODE>BITSTREAM</CODE> in
|
|
|
5907 |
<I>token_args</I> consists of these <CODE>SORT</CODE>s in the given
|
|
|
5908 |
order. If no token declaration or definition exists in the
|
|
|
5909 |
<CODE>CAPSULE</CODE>, the <CODE>BITSTREAM</CODE> cannot be read.
|
|
|
5910 |
<P>
|
|
|
5911 |
|
|
|
5912 |
<H3>5.53.2. <A NAME=M367>transfer_mode_cond</A></H3>
|
|
|
5913 |
<B>Encoding number</B>: 2<P>
|
|
|
5914 |
<PRE>
|
|
|
5915 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
5916 |
<I>e1</I>: BITSTREAM TRANSFER_MODE
|
|
|
5917 |
<I>e2</I>: BITSTREAM TRANSFER_MODE
|
|
|
5918 |
-> TRANSFER_MODE
|
|
|
5919 |
</PRE>
|
|
|
5920 |
<I>control</I> is evaluated. It will be a constant at install time
|
|
|
5921 |
under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
5922 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
5923 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
5924 |
and <I>e1</I> is ignored and never processed.
|
|
|
5925 |
<P>
|
|
|
5926 |
|
|
|
5927 |
<H3>5.53.3. <A NAME=M368>add_modes</A></H3>
|
|
|
5928 |
<B>Encoding number</B>: 3<P>
|
|
|
5929 |
<PRE>
|
|
|
5930 |
<I>md1</I>: TRANSFER_MODE
|
|
|
5931 |
<I>md2</I>: TRANSFER_MODE
|
|
|
5932 |
-> TRANSFER_MODE
|
|
|
5933 |
</PRE>
|
|
|
5934 |
A construction qualified by <I>add_modes</I> has both
|
|
|
5935 |
<CODE>TRANSFER_MODES</CODE> <I>md1</I> and <I>md2</I>. If <I>md1</I>
|
|
|
5936 |
is
|
|
|
5937 |
<I>standard_transfer_mode</I> then the result is <I>md2</I> and symmetrically.
|
|
|
5938 |
This operation is associative and commutative.
|
|
|
5939 |
<P>
|
|
|
5940 |
|
|
|
5941 |
<H3>5.53.4. <A NAME=M369>overlap</A></H3>
|
|
|
5942 |
<B>Encoding number</B>: 4<P>
|
|
|
5943 |
<PRE>
|
|
|
5944 |
-> TRANSFER_MODE
|
|
|
5945 |
</PRE>
|
|
|
5946 |
If <I>overlap</I> is used to qualify a <I>move_some</I> or an
|
|
|
5947 |
<I>assign_with_mode</I> for which <I>arg2</I> is a <I>contents</I>
|
|
|
5948 |
or
|
|
|
5949 |
<I>contents_with_mode</I>, then the source and destination might overlap.
|
|
|
5950 |
The transfer shall be made as if the data were copied from the source
|
|
|
5951 |
to an independent place and thence to the destination.
|
|
|
5952 |
<P>
|
|
|
5953 |
See <A HREF="spec10.html#48">Overlapping</A>.
|
|
|
5954 |
<P>
|
|
|
5955 |
|
|
|
5956 |
<H3>5.53.5. <A NAME=M370>standard_transfer_mode</A></H3>
|
|
|
5957 |
<B>Encoding number</B>: 5<P>
|
|
|
5958 |
<PRE>
|
|
|
5959 |
-> TRANSFER_MODE
|
|
|
5960 |
</PRE>
|
|
|
5961 |
This <CODE>TRANSFER_MODE</CODE> implies no special properties.
|
|
|
5962 |
<P>
|
|
|
5963 |
|
|
|
5964 |
<H3>5.53.6. <A NAME=M371>trap_on_nil</A></H3>
|
|
|
5965 |
<B>Encoding number</B>: 6<P>
|
|
|
5966 |
<PRE>
|
|
|
5967 |
-> TRANSFER_MODE
|
|
|
5968 |
</PRE>
|
|
|
5969 |
If <I>trap_on_nil</I> is used to qualify a <I>contents_with_mode</I>
|
|
|
5970 |
operation with a nil pointer argument, or an <I>assign_with_mode</I>
|
|
|
5971 |
whose arg1 is a nil pointer, or a <I>move_some</I> with either argument
|
|
|
5972 |
a nil pointer, the TDF exception <I>nil_access</I> is raised.
|
|
|
5973 |
<P>
|
|
|
5974 |
|
|
|
5975 |
<H3>5.53.7. <A NAME=M372>volatile</A></H3>
|
|
|
5976 |
<B>Encoding number</B>: 7<P>
|
|
|
5977 |
<PRE>
|
|
|
5978 |
-> TRANSFER_MODE
|
|
|
5979 |
</PRE>
|
|
|
5980 |
If <I>volatile</I> is used to qualify a construction it shall not
|
|
|
5981 |
be optimised away.
|
|
|
5982 |
<P>
|
|
|
5983 |
<I>This is intended to implement ANSI C's volatile construction. In
|
|
|
5984 |
this use, any volatile identifier should be declared as a <CODE>TAG</CODE>
|
|
|
5985 |
with used_as_volatile <CODE>ACCESS</CODE>.</I>
|
|
|
5986 |
<P>
|
|
|
5987 |
|
|
|
5988 |
<H3>5.53.8. <A NAME=M373>complete</A></H3>
|
|
|
5989 |
<B>Encoding number</B>: 8<P>
|
|
|
5990 |
<PRE>
|
|
|
5991 |
-> TRANSFER_MODE
|
|
|
5992 |
</PRE>
|
|
|
5993 |
A transfer qualified with complete shall leave the destination unchanged
|
|
|
5994 |
if the evaluation of the value transferred is left with a jump.
|
|
|
5995 |
<P>
|
|
|
5996 |
<P>
|
|
|
5997 |
|
|
|
5998 |
<HR>
|
|
|
5999 |
<H2>5.54. <A NAME=M374>UNIQUE</A></H2>
|
|
|
6000 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
6001 |
<B>Is coding extendable</B>: no<P>
|
|
|
6002 |
<P>
|
|
|
6003 |
These are used to provide world-wide unique names for <CODE>TOKEN</CODE>s
|
|
|
6004 |
and <CODE>TAG</CODE>s.
|
|
|
6005 |
<P>
|
|
|
6006 |
This implies a registry for allocating <CODE>UNIQUE</CODE> values.
|
|
|
6007 |
<P>
|
|
|
6008 |
|
|
|
6009 |
<H3>5.54.1. <A NAME=M375>make_unique</A></H3>
|
|
|
6010 |
<B>Encoding number</B>: 0<P>
|
|
|
6011 |
<PRE>
|
|
|
6012 |
<I>text</I>: SLIST(TDFIDENT)
|
|
|
6013 |
-> UNIQUE
|
|
|
6014 |
</PRE>
|
|
|
6015 |
Two <CODE>UNIQUE</CODE> values are equal if and only if they were
|
|
|
6016 |
constructed with equal arguments.
|
|
|
6017 |
<P>
|
|
|
6018 |
|
|
|
6019 |
<HR>
|
|
|
6020 |
<H2>5.55. <A NAME=M376>UNIT</A></H2>
|
|
|
6021 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
6022 |
<B>Is coding extendable</B>: no<P>
|
|
|
6023 |
A <CODE>UNIT</CODE> gathers together a <CODE>PROPS</CODE> and
|
|
|
6024 |
<CODE>LINK</CODE>s which relate the names by which objects are known
|
|
|
6025 |
inside the <CODE>PROPS</CODE> and names by which they are to be known
|
|
|
6026 |
across the whole of the enclosing <CODE>CAPSULE</CODE>.
|
|
|
6027 |
<P>
|
|
|
6028 |
|
|
|
6029 |
<H3>5.55.1. <A NAME=M377>make_unit</A></H3>
|
|
|
6030 |
<!-- BREAK 1 -->
|
|
|
6031 |
<B>Encoding number</B>: 0<P>
|
|
|
6032 |
<PRE>
|
|
|
6033 |
<I>local_vars</I>: SLIST(TDFINT)
|
|
|
6034 |
<I>lks</I>: SLIST(LINKS)
|
|
|
6035 |
<I>properties</I>: BYTESTREAM PROPS
|
|
|
6036 |
-> UNIT
|
|
|
6037 |
</PRE>
|
|
|
6038 |
<I>local_vars</I> gives the number of linkable entities of each kind.
|
|
|
6039 |
These numbers correspond (in the same order) to the variable sorts
|
|
|
6040 |
in <I>cap_linking</I> in <I>make_capsule</I>. The linkable entities
|
|
|
6041 |
will be represented by <CODE>TDFINT</CODE>s in the range 0 to the
|
|
|
6042 |
corresponding <I>nl</I>-1.
|
|
|
6043 |
<P>
|
|
|
6044 |
<I>lks</I> gives the <CODE>LINK</CODE>s for each kind of entity in
|
|
|
6045 |
the same order as in <I>local_vars</I>.
|
|
|
6046 |
<P>
|
|
|
6047 |
The <I>properties</I> will be a <CODE>PROPS</CODE> of a form dictated
|
|
|
6048 |
by the unit identification, see <A HREF="#M53">make_capsule</A>.
|
|
|
6049 |
<P>
|
|
|
6050 |
The length of <I>lks</I> will be either 0 or equal to the length of
|
|
|
6051 |
<I>cap_linking</I> in <I>make_capsule</I>.
|
|
|
6052 |
<P>
|
|
|
6053 |
|
|
|
6054 |
<HR>
|
|
|
6055 |
<H2>5.56. <A NAME=M378>VARIETY</A></H2>
|
|
|
6056 |
<B>Number of encoding bits</B>: 2<BR>
|
|
|
6057 |
<B>Is coding extendable</B>: yes<P>
|
|
|
6058 |
These describe the different kinds of integer which can occur at run
|
|
|
6059 |
time. The fundamental construction consists of a <CODE>SIGNED_NAT</CODE>
|
|
|
6060 |
for the lower bound of the range of possible values, and a
|
|
|
6061 |
<CODE>SIGNED_NAT</CODE> for the upper bound (inclusive at both ends).
|
|
|
6062 |
<P>
|
|
|
6063 |
There is no limitation on the magnitude of these bounds in TDF, but
|
|
|
6064 |
an installer may specify limits. See
|
|
|
6065 |
<A HREF="spec10.html#51">Representing integers</A>.
|
|
|
6066 |
<P>
|
|
|
6067 |
|
|
|
6068 |
<H3>5.56.1. <A NAME=M379>var_apply_token</A></H3>
|
|
|
6069 |
<B>Encoding number</B>: 1<P>
|
|
|
6070 |
<PRE>
|
|
|
6071 |
<I>token_value</I>: TOKEN
|
|
|
6072 |
<I>token_args</I>: BITSTREAM <I>param_sorts(token_value)</I>
|
|
|
6073 |
-> VARIETY
|
|
|
6074 |
</PRE>
|
|
|
6075 |
The token is applied to the arguments to give a <CODE>VARIETY</CODE>.
|
|
|
6076 |
<P>
|
|
|
6077 |
If there is a definition for <I>token_value</I> in the <CODE>CAPSULE</CODE>
|
|
|
6078 |
then <I>token_args</I> is a <CODE>BITSTREAM</CODE> encoding of the
|
|
|
6079 |
<CODE>SORT</CODE>s of its parameters, in the order specified.
|
|
|
6080 |
<P>
|
|
|
6081 |
|
|
|
6082 |
<H3>5.56.2. <A NAME=M380>var_cond</A></H3>
|
|
|
6083 |
<B>Encoding number</B>: 2<P>
|
|
|
6084 |
<PRE>
|
|
|
6085 |
<I>control</I>: EXP INTEGER(<I>v</I>)
|
|
|
6086 |
<I>e1</I>: BITSTREAM VARIETY
|
|
|
6087 |
<I>e2</I>: BITSTREAM VARIETY
|
|
|
6088 |
-> VARIETY
|
|
|
6089 |
</PRE>
|
|
|
6090 |
The <I>control</I> is evaluated. It will be a constant at install
|
|
|
6091 |
time under the constant evaluation rules. If it is non-zero, <I>e1</I>
|
|
|
6092 |
is installed at this point and <I>e2</I> is ignored and never processed.
|
|
|
6093 |
If <I>control</I> is zero then <I>e2</I> is installed at this point
|
|
|
6094 |
and <I>e1</I> is ignored and never processed.
|
|
|
6095 |
<P>
|
|
|
6096 |
|
|
|
6097 |
<H3>5.56.3. <A NAME=M381>var_limits</A></H3>
|
|
|
6098 |
<B>Encoding number</B>: 3<P>
|
|
|
6099 |
<PRE>
|
|
|
6100 |
<I>lower_bound</I>: SIGNED_NAT
|
|
|
6101 |
<I>upper_bound</I>: SIGNED_NAT
|
|
|
6102 |
-> VARIETY
|
|
|
6103 |
</PRE>
|
|
|
6104 |
<I>lower_bound</I> is the lower limit (inclusive) of the range of
|
|
|
6105 |
values which shall be representable in the resulting <CODE>VARIETY</CODE>,
|
|
|
6106 |
and <I>upper_bound</I> is the upper limit (inclusive).
|
|
|
6107 |
<P>
|
|
|
6108 |
|
|
|
6109 |
<H3>5.56.4. <A NAME=M382>var_width</A></H3>
|
|
|
6110 |
<B>Encoding number</B>: 4<P>
|
|
|
6111 |
<PRE>
|
|
|
6112 |
<I>signed_width</I>: BOOL
|
|
|
6113 |
<I>width</I>: NAT
|
|
|
6114 |
-> VARIETY
|
|
|
6115 |
</PRE>
|
|
|
6116 |
If <I>signed_width</I> is <I>true</I> then this construction is equivalent
|
|
|
6117 |
to <I>var_limits</I>(-2<SUP><I>width</I>-1</SUP>, 2<SUP><I>width</I>-1</SUP>-1).
|
|
|
6118 |
If <I>signed_width</I> is <I>false</I> then this construction is <I>var_limits
|
|
|
6119 |
</I>(0, 2<SUP><I>width</I></SUP>-1).
|
|
|
6120 |
<P>
|
|
|
6121 |
|
|
|
6122 |
<HR>
|
|
|
6123 |
<H2>5.57. <A NAME=M383>VERSION_PROPS</A></H2>
|
|
|
6124 |
<B>Number of encoding bits</B>: 0<BR>
|
|
|
6125 |
<B>Is coding extendable</B>: no<BR>
|
|
|
6126 |
<B>Unit identification</B>: <I>versions</I><P>
|
|
|
6127 |
This <CODE>UNIT</CODE> gives information about version numbers and
|
|
|
6128 |
user information.
|
|
|
6129 |
<P>
|
|
|
6130 |
|
|
|
6131 |
<H3>5.57.1. <A NAME=M384>make_versions</A></H3>
|
|
|
6132 |
<B>Encoding number</B>: 0<P>
|
|
|
6133 |
<PRE>
|
|
|
6134 |
<I>version_info</I>: SLIST(VERSION)
|
|
|
6135 |
-> VERSION_PROPS
|
|
|
6136 |
</PRE>
|
|
|
6137 |
Contains version information.
|
|
|
6138 |
<P>
|
|
|
6139 |
|
|
|
6140 |
<HR>
|
|
|
6141 |
<H2>5.58. <A NAME=M385>VERSION</A></H2>
|
|
|
6142 |
<B>Number of encoding bits</B>: 1<BR>
|
|
|
6143 |
<B>Is coding extendable</B>: yes<P>
|
|
|
6144 |
|
|
|
6145 |
<H3>5.58.1. <A NAME=M386>make_version</A></H3>
|
|
|
6146 |
<B>Encoding number</B>: 1<P>
|
|
|
6147 |
<PRE>
|
|
|
6148 |
<I>major_version</I>: TDFINT
|
|
|
6149 |
<I>minor_version</I>: TDFINT
|
|
|
6150 |
-> VERSION
|
|
|
6151 |
</PRE>
|
|
|
6152 |
The major and minor version numbers of the TDF used. An increase in
|
|
|
6153 |
minor version number means an extension of facilities, an increase
|
|
|
6154 |
in major version number means an incompatible change. TDF with the
|
|
|
6155 |
same major number but a lower minor number than the installer shall
|
|
|
6156 |
install correctly.
|
|
|
6157 |
<P>
|
|
|
6158 |
For TDF conforming to this specification the major number will be
|
|
|
6159 |
4 and the minor number will be 0.
|
|
|
6160 |
<P>
|
|
|
6161 |
Every <CODE>CAPSULE</CODE> will contain at least one <I>make_version</I>
|
|
|
6162 |
construct.
|
|
|
6163 |
<P>
|
|
|
6164 |
|
|
|
6165 |
<H3>5.58.2. <A NAME=M387>user_info</A></H3>
|
|
|
6166 |
<B>Encoding number</B>: 2<P>
|
|
|
6167 |
<PRE>
|
|
|
6168 |
<I>information</I>: STRING(<I>k, n</I>)
|
|
|
6169 |
-> VERSION
|
|
|
6170 |
</PRE>
|
|
|
6171 |
This is (usually character) information included in the TDF for labelling
|
|
|
6172 |
purposes.
|
|
|
6173 |
<P>
|
|
|
6174 |
<I>information</I> will be produced by <I>make_string</I>.
|
|
|
6175 |
<P>
|
|
|
6176 |
<HR>
|
|
|
6177 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
6178 |
Copyright © 1998.</I></P>
|
|
|
6179 |
</BODY>
|
|
|
6180 |
</HTML>
|