| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>Constants</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<A NAME=S75>
|
|
|
8 |
<H1>TDF Guide, Issue 4.0 </H1>
|
|
|
9 |
<A HREF="guide12.html">
|
|
|
10 |
<H3>January 1998</H3>
|
|
|
11 |
<IMG SRC="../images/next.gif" ALT="next section"></A>
|
|
|
12 |
<A HREF="guide10.html">
|
|
|
13 |
<IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
14 |
<A HREF="guide1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
15 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
16 |
</A>
|
|
|
17 |
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
|
|
|
18 |
<HR>
|
|
|
19 |
<DL>
|
|
|
20 |
<DT><A HREF="#S76"><B>9.1 </B> - _cond constructors</A><DD>
|
|
|
21 |
<DT><A HREF="#S77"><B>9.2 </B> - Primitive constant constructors</A><DD>
|
|
|
22 |
</DL>
|
|
|
23 |
<HR>
|
|
|
24 |
<H1>9 <A NAME=0>Constants</H1>
|
|
|
25 |
The representation of constants clearly has peculiar difficulties
|
|
|
26 |
in any architecture neutral format. Leaving aside any problems of
|
|
|
27 |
how numbers are to be represented, we also have the situation where
|
|
|
28 |
a "constant" can have different values on different platforms.
|
|
|
29 |
An obvious example would be the size of a structure which, although
|
|
|
30 |
it is a constant of any particular run of a program, may have different
|
|
|
31 |
values on different machines. Further, this constant is in general
|
|
|
32 |
the result of some computation involving the sizes of its components
|
|
|
33 |
which are not known until the platform is chosen. In TDF, sizes are
|
|
|
34 |
always derived from some EXP OFFSET constructed using the various
|
|
|
35 |
OFFSET arithmetic operations on primitives like shape_offset and offset_zero.
|
|
|
36 |
Most such EXP OFFSETs produced are in fact constants of the platform;
|
|
|
37 |
they include field displacements of structure as well as their sizes.
|
|
|
38 |
TDF assumes that, if these EXPs can be evaluated at translate-time
|
|
|
39 |
(i.e. when the sizes and alignments of primitive objects are known),
|
|
|
40 |
then they must be evaluated there. An example of why this is so arises
|
|
|
41 |
in make_compound; the SHAPE of its result EXP depends on its <I>arg1</I>
|
|
|
42 |
EXP OFFSET parameter and all SHAPEs must be translate-time values.
|
|
|
43 |
<P>
|
|
|
44 |
An initialisation of a TAGDEF is a constant in this sense
|
|
|
45 |
<A NAME=footnote76 HREF="footnote.html#76">*</A>; this allows one
|
|
|
46 |
to ignore any difficulties about their order of evaluation in the
|
|
|
47 |
UNIT and consequently the order of evaluation of UNITs. Once again
|
|
|
48 |
all the EXPs which are initialisations must be evaluated before the
|
|
|
49 |
program is run; this obviously includes any make_proc or make_general_proc.
|
|
|
50 |
. The limitation on an initialisation EXP to ensure this is basically
|
|
|
51 |
that one cannot take the contents of a variable declared outside the
|
|
|
52 |
EXP after all tokens and conditional evaluation is taken into account.
|
|
|
53 |
In other words, each TDF translator effectively has an TDF interpreter
|
|
|
54 |
which can do evaluation of expressions (including conditionals etc.)
|
|
|
55 |
involving only constants such as numbers, sizes and addresses of globals.
|
|
|
56 |
This corresponds very roughly to the kind of initialisations of globals
|
|
|
57 |
that are permissible in C; for a more precise definition, see (S7.3)</A>.<P>
|
|
|
58 |
<A NAME=S76>
|
|
|
59 |
<HR><H2>9.1. <A NAME=1>_cond constructors</H2>
|
|
|
60 |
Another place where translate-time evaluation of constants is mandated
|
|
|
61 |
is in the various _cond constructors which give a kind of "conditional
|
|
|
62 |
compilation" facility; every SORT which has a SORTNAME, other
|
|
|
63 |
that TAG, TOKEN and LABEL, has one of these constructors e.g. exp_cond:<P>
|
|
|
64 |
<PRE>
|
|
|
65 |
<I> control</I>: EXP INTEGER(<I>v</I>)
|
|
|
66 |
<I> e1</I>: BITSTREAM EXP <I>x</I>
|
|
|
67 |
<I> e2</I>: BITSTREAM EXP <I>y</I>
|
|
|
68 |
-> EXP <I>x</I> or EXP <I>y</I>
|
|
|
69 |
</PRE>
|
|
|
70 |
The constant, <I>control</I>, is evaluated at translate time. If it
|
|
|
71 |
is not zero the entire construction is replaced by the EXP in <I>e1</I>;
|
|
|
72 |
otherwise it is replaced by the one in <I>e2</I>. In either case,
|
|
|
73 |
the other BITSTREAM is totally ignored; it even does not need to be
|
|
|
74 |
sensible TDF. This kind of construction is use extensively in C pre-processing
|
|
|
75 |
directives e.g.:<P>
|
|
|
76 |
<PRE>
|
|
|
77 |
#if (sizeof(int) == sizeof(long)) ...
|
|
|
78 |
|
|
|
79 |
</PRE>
|
|
|
80 |
<A NAME=S77>
|
|
|
81 |
<HR><H2>9.2. Primitive constant constructors</H2>
|
|
|
82 |
Integer constants are constructed using make_int:<P>
|
|
|
83 |
<PRE>
|
|
|
84 |
<I> v</I>: VARIETY
|
|
|
85 |
<I> value</I>: SIGNED_NAT
|
|
|
86 |
-> EXP INTEGER(<I>v</I>)
|
|
|
87 |
</PRE>
|
|
|
88 |
The SIGNED_NAT <I>value</I> is an encoding of the binary value required
|
|
|
89 |
for the integer; this value must lie within the limits given by <I>v</I>.
|
|
|
90 |
I have been rather slip-shod in writing down examples of integer constants
|
|
|
91 |
earlier in this document; where I have written 1 as an integer EXP,
|
|
|
92 |
for example, I should have written make_int(v, 1) where v is some
|
|
|
93 |
appropriate VARIETY.<P>
|
|
|
94 |
Constants for both floats and strings use STRINGs. A constant string
|
|
|
95 |
is just an particular example of make_nof_int:<P>
|
|
|
96 |
<PRE>
|
|
|
97 |
<I> v</I>: VARIETY
|
|
|
98 |
<I> str</I>: STRING(<I>k, n</I>)
|
|
|
99 |
-> EXP NOF(<I>n</I>, INTEGER(<I>v</I>))
|
|
|
100 |
</PRE>
|
|
|
101 |
Each unsigned integer in <I>str</I> must lie in the variety <I>v</I>
|
|
|
102 |
and the result is the constant array whose elements are the integers
|
|
|
103 |
considered to be of VARIETY <I>v</I>. An ASCI-C constant string might
|
|
|
104 |
have <I>v</I> = variety(-128,127) and <I>k</I> = 7; however, make_nof_int
|
|
|
105 |
can be used to make strings of any INTEGER VARIETY; a the elements
|
|
|
106 |
of a Unicode string would be integers of size 16 bits.<P>
|
|
|
107 |
A floating constant uses a STRING which contains the ASCI characters
|
|
|
108 |
of a expansion of the number to some base in make_floating:<P>
|
|
|
109 |
<PRE>
|
|
|
110 |
<I> f</I>: FLOATING_VARIETY
|
|
|
111 |
<I> rm</I>: ROUNDING_MODE
|
|
|
112 |
<I> sign</I>: BOOL
|
|
|
113 |
<I> mantissa</I>: STRING(<I>k, n</I>)
|
|
|
114 |
<I> base</I>: NAT
|
|
|
115 |
<I> exponent</I>: SIGNED_NAT
|
|
|
116 |
-> EXP FLOATING(<I>f</I>)
|
|
|
117 |
</PRE>
|
|
|
118 |
For a normal floating point number, each integer in <I>mantissa</I>
|
|
|
119 |
is either the ASCI `.'-symbol or the ASCI representation of a digit
|
|
|
120 |
of the representation in the given <I>base</I>; i.e. if c is the ASCI
|
|
|
121 |
symbol, the digit value is c-'0'. The resulting floating point number
|
|
|
122 |
has SHAPE FLOATING(f) and value <I>mantissa</I> *<I> base</I><I> exponent</I>
|
|
|
123 |
rounded according to <I>rm</I>. Usually the base will be 10 (sometimes
|
|
|
124 |
2) and the rounding mode to_nearest. Any floating-point evaluation
|
|
|
125 |
of expressions done at translate-time will be done to an accuracy
|
|
|
126 |
greater that implied by the FLOATING_VARIETY involved, so that floating
|
|
|
127 |
constants will be as accurate as the platform permits.<P>
|
|
|
128 |
The make_floating construct does not apply apply to a complex FLOATING_VARIETY
|
|
|
129 |
<I>f</I>; to construct a complex constant use make_complex with two
|
|
|
130 |
make_floating arguments.<P>
|
|
|
131 |
Constants are also provided to give unique null values for pointers,
|
|
|
132 |
label values and procs i.e.: make_null_ptr, make_null_local_lv and
|
|
|
133 |
make_null_proc. Any significant use of these values (e.g. taking the
|
|
|
134 |
contents of a null pointer) is undefined, but they can be assigned
|
|
|
135 |
and used in tests in the normal way.<P>
|
|
|
136 |
<HR>
|
|
|
137 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
138 |
Copyright © 1998.</I></P>
|
|
|
139 |
</BODY>
|
|
|
140 |
</HTML>
|