Rev 2 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>Constants</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<A NAME=S75>
<H1>TDF Guide, Issue 4.0 </H1>
<A HREF="guide12.html">
<H3>January 1998</H3>
<IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="guide10.html">
<IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="guide1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>
<DL>
<DT><A HREF="#S76"><B>9.1 </B> - _cond constructors</A><DD>
<DT><A HREF="#S77"><B>9.2 </B> - Primitive constant constructors</A><DD>
</DL>
<HR>
<H1>9 <A NAME=0>Constants</H1>
The representation of constants clearly has peculiar difficulties
in any architecture neutral format. Leaving aside any problems of
how numbers are to be represented, we also have the situation where
a "constant" can have different values on different platforms.
An obvious example would be the size of a structure which, although
it is a constant of any particular run of a program, may have different
values on different machines. Further, this constant is in general
the result of some computation involving the sizes of its components
which are not known until the platform is chosen. In TDF, sizes are
always derived from some EXP OFFSET constructed using the various
OFFSET arithmetic operations on primitives like shape_offset and offset_zero.
Most such EXP OFFSETs produced are in fact constants of the platform;
they include field displacements of structure as well as their sizes.
TDF assumes that, if these EXPs can be evaluated at translate-time
(i.e. when the sizes and alignments of primitive objects are known),
then they must be evaluated there. An example of why this is so arises
in make_compound; the SHAPE of its result EXP depends on its <I>arg1</I>
EXP OFFSET parameter and all SHAPEs must be translate-time values.
<P>
An initialisation of a TAGDEF is a constant in this sense
<A NAME=footnote76 HREF="footnote.html#76">*</A>; this allows one
to ignore any difficulties about their order of evaluation in the
UNIT and consequently the order of evaluation of UNITs. Once again
all the EXPs which are initialisations must be evaluated before the
program is run; this obviously includes any make_proc or make_general_proc.
. The limitation on an initialisation EXP to ensure this is basically
that one cannot take the contents of a variable declared outside the
EXP after all tokens and conditional evaluation is taken into account.
In other words, each TDF translator effectively has an TDF interpreter
which can do evaluation of expressions (including conditionals etc.)
involving only constants such as numbers, sizes and addresses of globals.
This corresponds very roughly to the kind of initialisations of globals
that are permissible in C; for a more precise definition, see (S7.3)</A>.<P>
<A NAME=S76>
<HR><H2>9.1. <A NAME=1>_cond constructors</H2>
Another place where translate-time evaluation of constants is mandated
is in the various _cond constructors which give a kind of "conditional
compilation" facility; every SORT which has a SORTNAME, other
that TAG, TOKEN and LABEL, has one of these constructors e.g. exp_cond:<P>
<PRE>
<I> control</I>: EXP INTEGER(<I>v</I>)
<I> e1</I>: BITSTREAM EXP <I>x</I>
<I> e2</I>: BITSTREAM EXP <I>y</I>
-> EXP <I>x</I> or EXP <I>y</I>
</PRE>
The constant, <I>control</I>, is evaluated at translate time. If it
is not zero the entire construction is replaced by the EXP in <I>e1</I>;
otherwise it is replaced by the one in <I>e2</I>. In either case,
the other BITSTREAM is totally ignored; it even does not need to be
sensible TDF. This kind of construction is use extensively in C pre-processing
directives e.g.:<P>
<PRE>
#if (sizeof(int) == sizeof(long)) ...
</PRE>
<A NAME=S77>
<HR><H2>9.2. Primitive constant constructors</H2>
Integer constants are constructed using make_int:<P>
<PRE>
<I> v</I>: VARIETY
<I> value</I>: SIGNED_NAT
-> EXP INTEGER(<I>v</I>)
</PRE>
The SIGNED_NAT <I>value</I> is an encoding of the binary value required
for the integer; this value must lie within the limits given by <I>v</I>.
I have been rather slip-shod in writing down examples of integer constants
earlier in this document; where I have written 1 as an integer EXP,
for example, I should have written make_int(v, 1) where v is some
appropriate VARIETY.<P>
Constants for both floats and strings use STRINGs. A constant string
is just an particular example of make_nof_int:<P>
<PRE>
<I> v</I>: VARIETY
<I> str</I>: STRING(<I>k, n</I>)
-> EXP NOF(<I>n</I>, INTEGER(<I>v</I>))
</PRE>
Each unsigned integer in <I>str</I> must lie in the variety <I>v</I>
and the result is the constant array whose elements are the integers
considered to be of VARIETY <I>v</I>. An ASCI-C constant string might
have <I>v</I> = variety(-128,127) and <I>k</I> = 7; however, make_nof_int
can be used to make strings of any INTEGER VARIETY; a the elements
of a Unicode string would be integers of size 16 bits.<P>
A floating constant uses a STRING which contains the ASCI characters
of a expansion of the number to some base in make_floating:<P>
<PRE>
<I> f</I>: FLOATING_VARIETY
<I> rm</I>: ROUNDING_MODE
<I> sign</I>: BOOL
<I> mantissa</I>: STRING(<I>k, n</I>)
<I> base</I>: NAT
<I> exponent</I>: SIGNED_NAT
-> EXP FLOATING(<I>f</I>)
</PRE>
For a normal floating point number, each integer in <I>mantissa</I>
is either the ASCI `.'-symbol or the ASCI representation of a digit
of the representation in the given <I>base</I>; i.e. if c is the ASCI
symbol, the digit value is c-'0'. The resulting floating point number
has SHAPE FLOATING(f) and value <I>mantissa</I> *<I> base</I><I> exponent</I>
rounded according to <I>rm</I>. Usually the base will be 10 (sometimes
2) and the rounding mode to_nearest. Any floating-point evaluation
of expressions done at translate-time will be done to an accuracy
greater that implied by the FLOATING_VARIETY involved, so that floating
constants will be as accurate as the platform permits.<P>
The make_floating construct does not apply apply to a complex FLOATING_VARIETY
<I>f</I>; to construct a complex constant use make_complex with two
make_floating arguments.<P>
Constants are also provided to give unique null values for pointers,
label values and procs i.e.: make_null_ptr, make_null_local_lv and
make_null_proc. Any significant use of these values (e.g. taking the
contents of a null pointer) is undefined, but they can be assigned
and used in tests in the normal way.<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>