Rev 7 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<?xml version="1.0" standalone="no"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<!--
$Id$
-->
<book>
<bookinfo>
<title>PL_TDF Definition</title>
<corpauthor>The TenDRA Project</corpauthor>
<author>
<firstname>Jeroen</firstname>
<surname>Ruigrok van der Werven</surname>
</author>
<authorinitials>JRvdW</authorinitials>
<pubdate>2005</pubdate>
<copyright>
<year>2004</year>
<year>2005</year>
<holder>The TenDRA Project</holder>
</copyright>
<copyright>
<year>1998</year>
<holder>DERA</holder>
</copyright>
</bookinfo>
<chapter id="intro">
<title>Introduction</title>
<para>PL_TDF is a language in the lineage of Wirth's PL360 and its later
derivatives. The basic idea in PL360 was to give one an assembler in
which one could express all of the order-code of the IBM 360 while
still preserving the logical structure of the program using familiar
programming constructs. If one had to produce a program at the code
level, this approach was much preferable to writing "flat" assembly
code using a traditional assembler, as anyone who has used both can
testify.</para>
<para>In the TDF "machine" the problem is not lack of structure at its
"assembly" level, but rather too much of it; one loses the sense of a
TDF program because of its deeply nested structure. Also the naming
conventions of TDF are designed to make them tractable to machine
manipulation, rather than human reading and writing. However, the
approach is basically the same. PL_TDF provides shorthand notations
for the commonly occuring control structures and operations while
still allowing one to use the standard TDF constructors which, in
turn, may have shorthand notations for their parameters. The naming is
always done by identifiers where the sort of the name is determined by
its declaration, or by context.</para>
<para>The TDF derived from PL_TDF is guaranteed to be SORT correct;
however, there is no SHAPE checking, so one can still make illegal
TDF.</para>
</chapter>
<chapter>
<title>Notation</title>
<sect1 id="S3">
<title>Syntax description</title>
<para>Words enclosed in angle brackets, < >, form non-terminal
symbols. Other symbols and words stand for themselves as terminal
symbols. An expansion of a non-terminal is indicated using ::= with
its expansion given as a sequence (possibly empty) of terminals and
non-terminals. For example:
<programlisting>
<Exp> ::= * <ident>
</programlisting>
is a possible expansion of an EXP SORT. If the word for the
non-terminal starts with a capital letter then it will be totally
described by a set of such expansions; otherwise the expansion of
the non-terminal will be given by other methods in the text.</para>
<para>The post-fix -Opt on a non terminal is an abreviation allowing
an empty expansion. For example:
<programlisting>
<Access>-Opt
</programlisting>
is equivalent to the use of another non-terminal
<AccessOption> whose expansions are:
<programlisting>
<AccessOption> ::=
<AccessOption> ::= <Access>
</programlisting>
The post-fix -List on a non terminal is an abreviation for lists of
objects seperated by the ,-symbol. For example:
<programlisting>
<Exp>-List
</programlisting>
is equivalent to the use of another non-terminal <ExpList>
whose expansions are:
<programlisting>
<ExpList> ::= <Exp>
<ExpList> ::= <ExpList> , <Exp>
</programlisting>
Both of these post-fix notations are also used with sequences of
terminals and non-terminals within the angle brackets with the same
kind of expansion. In these cases, the expansion within the angle
brackets form an anonymous non-terminal.</para>
</sect1>
<sect1 id="S4">
<title>Lexical Units</title>
<para>The terminal symbols ( ), [ ], and { } always occur as
parenthetic pairs and never form part of other terminal
symbols.</para>
<para>The terminal symbols , ; and : are similarly terminators for
other terminal symbols.</para>
<para>White space is a terminator for other terminal symbols but is
otherwise ignored except in strings.</para>
<para>All other terminal symbols are sequences of ACSII symbols not
including the above. These are divided into seven classes: keywords,
TDF constructors, operators, <integer_denotation>s,
<floating_denotation>s, <string>s and
<ident>s.</para>
<para>The keywords and operators are expressed directly in the syntax
description. The TDF constructors are those given in the TDF
specification which have first-class SORTs as parameters and
results.</para>
<para>An <integer_denotatation> allows one to express an integer
in any base less than 16, with the default being 10.
<programlisting>
<integer_denotation> ::= <digit>
<integer_denotation> ::= <integer_denotation> <digit>
<integer_denotation> ::= <base> <integer_denotation>
<base> ::= <integer_denotation> r
</programlisting>
Examples are 31, 16r1f, 8r37, 2r11111 - all giving the same
value.</para>
<para>A <floating_denotation> is an <integer_denotation>
followed by the . symbol and a sequence of digits. The radix of the
<floating_denotation> is given by the base of its component
<integer_denotation></para>
<para>A <string> is the same as a C string - any sequence of
characters within " ". The same C conventions hold for \ within
strings for single characters.</para>
<para>A <character> is an string character within ` `. The same
\ conventions hold.</para>
<para>An <ident> is any other sequence of characters. They will
be used to form names for TAGs, TOKENs, AL_TAGs and LABELs.</para>
</sect1>
<sect1 id="S5">
<title>Pre-processing</title>
<para>At the moment there is only one pre-processing directive. A line
starting with #include will textually include the following file
(named within string quotes), using the same path conventions as
C.</para>
<para>Comments may be included in the text using the /* ... */
notation; this differs slightly from the C convention in that
comments may be nested.</para>
</sect1>
</chapter>
<chapter>
<title>The Language</title>
<para>The basic philosophy of PL_TDF is to provide the "glue"
constructors of TDF automatically, while still allowing the programmer
to use the significant constructors in their most general form. By
"glue" constructors, I mean those like make_link, make_group etc.
which are there to provide tedious, but vital, constructions concerned
with linking and naming. The "significant" constructors really come in
two groups, depending on their resulting SORTs. There are those SORTs
like TOKDEC, whose SORTs are purely syntactic and can't be used as
results of token applications or _cond constructions. On the other
hand, the first-class SORTs, like EXP, can be used in those situations
and generally have a much richer set of constructors. These
first-class SORTs are precisely those which have SORTNAMEs. These
SORTNAMEs appear in PL_TDF as expansions of <Sortname>:
<programlisting>
<Sortname> ::= ACCESS
<Sortname> ::= AL_TAG
<Sortname> ::= ALIGNMENT
<Sortname> ::= BITFIELD_VARIETY
<Sortname> ::= BOOL
<Sortname> ::= ERROR_TREATMENT
<Sortname> ::= EXP
<Sortname> ::= FLOATING_VARIETY
<Sortname> ::= LABEL
<Sortname> ::= NAT
<Sortname> ::= NTEST
<Sortname> ::= ROUNDING_MODE
<Sortname> ::= SHAPE
<Sortname> ::= SIGNED_NAT
<Sortname> ::= STRING
<Sortname> ::= TAG
<Sortname> ::= TRANSFER_MODE
<Sortname> ::= VARIETY
</programlisting>
All of the significant constructors are expanded by non-terminals with
names related to their resulting SORT e.g. all EXPs are expanded by
<Exp> and all TOKDECs are expanded by <Tokdec>. Any
first-class SORT can be expanded by using the constructor names given
in the TDF specification, provided that the parameter SORTs are also
first-class. For example, the following are all valid expansions of
<Exp> :
<programlisting>
make_top
return(E) where E is an expansion of <Exp>
goto(L) where L is an expansion of <Label>
assign(E1, E2) where E1 and E2 are expansions of <Exp>
</programlisting>
Any such use of TDF constructors will be checked for the
SORT-correctness of their parameters. I will denote such a constructor
as an <exp_constructor>; similarly for all the other first-class
sorts.</para>
<para>Any of the first-class sorts may also be expanded by a token
application. Tokens in PL_TDF are given <ident> names by
<Tokdef> or <Tokdec> which must occur before their use in
applications. In applications, these names will be denoted by
<exp_token>, <shape_token> etc. , depending on the result
sort of their introduction.</para>
<para>The principle of "no use before declaration" also applies to
<ident> names given to TAGs.</para>
<sect1 id="S7">
<title>Program</title>
<para>The root expansion of a PL_TDF program is given by
<Program>:
<programlisting>
<Program> ::= <ElementList> Keep ( <Item>-List-Opt )
<ElementList> ::= <Element> ;
<ElementList> ::= <Element> ; <ElementList>
<Element> ::= <Tokdec>
<Element> ::= <Tokdef>
<Element> ::= <Tagdec>
<Element> ::= <Tagdef>
<Element> ::= <Altagdef>
<Element> ::= <Structdef>
<Element> ::= <Procdef>
<Item> ::= <tag>
<Item> ::= <token>
<item> ::= <altag>
</programlisting>
A <Program> consists of a list of definitions and declarations
giving meaning to various <ident>s, as TAGs, TOKENs and
AL_TAGs. The <Item>-List-Opt indicates which of these names
will be externally available via CAPSULE_LINKs; in addition any
other names which are declared but not defined will also be linked
externally.</para>
<para>A <Program> will produce a single TDF CAPSULE.</para>
<sect2 id="S8">
<title>Tokdec</title>
<para>A <Tokdec> introduces an <ident> as a TOKEN:
<programlisting>
<Tokdec> ::= Tokdec <ident><Signature>: [ <TokDecPar>-List-Opt ] <ResultSort>
<ResultSort> ::= <Sortname>
<TokDecPar> ::= <Sortname>
<TokDecPar> ::= TOKEN [ <TokDecPar>-List-Opt ] <ResultSort>
<Signature> ::= <String>-Opt
</programlisting>
This produces a TOKDEC in a tokdec UNIT of the CAPSULE. Further
uses of the introduced <ident> will be treated as a
<x-token> where x is given by the <ResultSort>.</para>
</sect2>
<sect2 id="S9">
<title>Tokdef</title>
<para>A <Tokdef> defines an <ident> as a TOKEN; this
<ident> may have previously been introduced by a
<Tokdec>:
<programlisting>
<Tokdef> ::= Tokdef <ident><Signature> = <Tok_Defn>
<Tok_Defn> ::= [ <TokDefPar>-List-Opt ] <ResultSort> <result_sort>
<TokDefPar> ::= <ident> : <TokDecPar>
<Signature> ::= <String>-Opt
</programlisting>
This produces a TOKDEF in a tokdef UNIT of the CAPSULE. The
expansion of <result_sort> depends on <ResultSort>,
e.g. if <ResultSort> is EXP then <result_sort> ::=
<Exp> and so on.</para>
<para>Each of the <ident>s in the <TokDefPar>s will be
names for tokens whose scope is <result_sort>. A use of such
a name within its scope will be expanded as a parameterless token
application of the appropriate sort given by its
<TokDecPar>. Note that this is still true if the
<TokDecPar> is a TOKEN - if a <TokDefPar> is:
<programlisting>
x: TOKEN[ LABEL ]EXP
</programlisting>
then x[L] is expanded as:
<programlisting>
exp_apply_token( token_apply_token(x, ()), L)
</programlisting>
<Tok_defn> also occurs in an expansion of <Token>, as
a parameter of a token application.</para>
</sect2>
<sect2 id="S10">
<title>Tagdec</title>
<para>A <Tagdec> introduces an <ident> as a TAG:
<programlisting>
<Tagdec> ::= <DecType> <ident> <Signature> <Access>-Opt : <Shape>
<DecType> ::= Vardec
<DecType> ::= Iddec
<DecType> ::= Commondec
<Signature> ::= <String>-Opt
</programlisting>
This produces a TAGDEC in a tagdec UNIT of the CAPSULE, using a
make_id_tagdec for the Iddec option, a make_var_tagdec for the
Vardec option and a common_tagdec for the Commondec option.</para>
<para>The <Shape>s in both <Tagdec>s and <Tagdef>s
will produce SHAPE TOKENs in a tagdef UNIT; these may be applied
in various shorthand operations on TAG <ident>s.</para>
</sect2>
<sect2 id="S11">
<title>Tagdef</title>
<para>A <Tagdef> defines an <ident> as a TAG. This
<ident> may have previously been introduced by a
<Tagdec>; if it has not the < : <Shape> >-Opt
below must not be empty and a TAGDEC will be produced for it.
<programlisting>
<Tagdef> ::= Var <ident><Signature> < : <Shape> >-Opt < = <Exp>>-Opt
</programlisting>
Produces a make_var_tagdef.
<programlisting>
<Tagdef> ::= Common <ident> <Signature>< : <Shape> >-Opt < = <Exp> >-Opt
</programlisting>
Produces a common_tagdef.
<programlisting>
<Tagdef> ::= Let <ident><Signature> < : <Shape> >-Opt = <Exp>
</programlisting>
Produces a make_id_tagdef.
<programlisting>
<Tagdef> ::= String <ident> <Variety>-Opt =<string>
</programlisting>
This is a shorthand for producing names which have the properties
of C strings. The <Variety>-Opt gives the variety of the
characters with the string, an empty option giving unsigned chars.
The TDF produced is a make_var_tagdef initialised by a
make_nof_int. This means that given a String definition:
<programlisting>
String format = "Result = %d\n"
</programlisting>
the tag <ident>, format, could be used straightforwardly as
the first parameter of printf - see <link linkend="S41">Section 4
(Example PL_TDF programs)</link>.</para>
</sect2>
<sect2 id="S12">
<title>Altagdef</title>
<para>An <Altagdef> defines an <ident> as an AL_TAG:
<programlisting>
<Altagdef> ::= Al_tagdef <ident> = <Alignment>
</programlisting>
This produces an AL_TAGDEF in an al_tagdef UNIT of the CAPSULE. The
<ident> concerned can be previously used in as an expansion of
<Alignment>.</para>
</sect2>
<sect2 id="S13">
<title>Structdef</title>
<para>A <Structdef> defines a TOKEN for a structure SHAPE,
together with two TOKENs for each field of the structure to allow
easy access to the offsets and contents of the field:
<programlisting>
<Structdef> ::= Struct <Structname> ( <Field>-List )
<Structname> ::= <ident>
<Field> ::= <Fieldname> : <Shape>
<Fieldname> ::= <ident>
</programlisting>
This produces a TOKDEF in a tokdef UNIT defining
<Structname> as a SHAPE token whose expansion is an EXP
OFFSET(a1,a2) where the OFFSET is the size of the structure with
standard TDF padding and offset addition of the component SHAPEs
and sizes (note that this may not correspond precisely with C
sizes).Each <Fieldname> will produce two TOKENs. The first
is named by <Fieldname> itself and is a [EXP]EXP which gives
the value of the field of its structure parameter. The second is
named by prefixing <Fieldname> by the.-symbol and is an [
]EXP giving the OFFSET of the field from the start of the
structure. Thus given:
<programlisting>
Struct Complex (re: Double, im: Double)
</programlisting>
Complex is a TOKEN for a SHAPE defining two Doubles; re[E] and
im[E] will extract the components of E where E is an EXP of shape
Complex; .re and.im give EXP OFFSETs of the the two fields from
the start of the structure.</para>
</sect2>
<sect2 id="S14">
<title>Procdef</title>
<para>A <Procdef> defines a TAG to be a procedure; it is
simply an abreviation of a an Iddec <Tagdef>:
<programlisting>
<Procdef> ::= Proc <ident> = <Proc_Defn>
<Proc_Defn> ::= <Simple_Proc>
<Proc_Defn> ::= <General_Proc>
<Simple_Proc> ::= <Shape> ( <TagShAcc>-List-Opt <VarIntro>-Opt ) <ClosedExp>
<TagShAcc> ::= <Parametername> <Access>-Opt : <Shape>
<Parametername> ::= <ident>
<VarIntro> ::= Varpar <Varparname> : <Alignment>
<Varparname> ::= <ident>
</programlisting>
<programlisting>
<General_Proc> ::= General <Shape> ( <For_Callers>; <For_Callees>) <ProcProps>-Opt <ClosedExp>
<For_Callers> ::= <TagShAcc>-List-Opt <...>-Opt
<For_Callees> ::= <TagShAcc>-List-Opt <...>-Opt
<ProcProps> ::= <untidy>-Opt <check_stack>-Opt
</programlisting>
A <Procdef> produces a TAGDEF in a tagdef UNIT and and,
possibly, a TAGDEC in a tagdef UNIT.</para>
<para>A <Simple_Proc> produces a make_proc with the obvious
operands. The scope of the tag names introduced by
<Parametername> and <Varparname> is the
<ClosedExp> (see <link linkend="S36">section
3.3</link>).</para>
<para>A <General_Proc> produces a make_general_proc with
formal caller parameters given by <For_callers> and the
formal callee parameters given by <For_callees>; in both
cases the <...> option says that the procedure can be called
with a variable number of parameters. The scope of the tag names
are the same as for <Simple_Proc>.</para>
</sect2>
</sect1>
<sect1 id="S15">
<title>First-class SORT expansions</title>
<para>All of the first-class sorts have similar expansions for native
TDF constructions and for token applications. I shall take
<Shape> as the paradigm sort and allow the reader to conjugate
the following for the the other sorts.</para>
<para>Those first-class sorts which include the _cond constructions
denote them in the same way:
<programlisting>
<Shape> ::= SHAPE ? ( <Exp>, <Shape>, <Shape> )
</programlisting>
This produces a shape_cond with the obvious parameters.</para>
<para>Each constructor for <Shape> with parameters which are
first-class sorts can be expanded:
<programlisting>
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
</programlisting>
Each <constructor_param> will be the first_class SORT
expansion, required by the <shape_constructor> as in the TDF
specification eg the constructor, pointer, requires a
<constructor_param> ::= <Alignment>.</para>
<para>Any <ident> which is declared to be a
<shape_token> by a TOKDEF or TOKDEC can be expanded:
<programlisting>
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
</programlisting>
This will produce a shape_apply_token with the appropriate
parameters. Each <token_param> will be the first-class SORT
expansion required by the SORT given by the <TokDecPar> of the
TOKDEF or TOKDEC which introduced <shape_token>.</para>
<sect2 id="S16">
<title>Access</title>
<para>
<programlisting>
<Access> ::= ACCESS ? ( <Exp> , <Access> , <Access> )
<Access> ::= <access_constructor> < ( <constructor_param>-List ) >-Opt
<Access> ::= <access_token> < [ <token_param>-List ] >-Opt
</programlisting>
There are no expansions of <Access> other than the standard
ones.</para>
</sect2>
<sect2 id="S17">
<title>Al_tag</title>
<para>
<programlisting>
<Al_tag> ::= <al_tag_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard token expansion.
<programlisting>
<Al_tag> ::= <ident>
</programlisting>
Any <ident> found as an expansion of <Al_tag> will be
declared as the name for an AL_TAG.</para>
</sect2>
<sect2 id="S18">
<title>Alignment</title>
<para>
<programlisting>
<Alignment> ::= ALIGNMENT ? ( <Exp> , <Alignment> , <Alignment> )
<Alignment> ::= <alignment_constructor> < ( <constructor_param>-List ) >-Opt
<Alignment> ::= <alignment_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Alignment> ::= <Al_tag>
</programlisting>
This results in an obtain_al_tag of the AL_TAG.
<programlisting>
<Alignment> ::= ( <Alignment>-List-Opt )
</programlisting>
The <Alignment>s in the <Alignment>-List are united
using unite_alignments. The empty option results in the top
ALIGNMENT.</para>
</sect2>
<sect2 id="S19">
<title>Bitfield_variety</title>
<para>
<programlisting>
<Bitfield_variety> ::= BITFIELD_VARIETY ? ( <Exp> , <Bitfield_variety>, <Bitfield_variety>)
<Bitfield_variety> ::= <bitfield_variety_constructor> < ( <constructor_param>-List ) >-Opt
<Bitfield_variety> ::= <bitfield_variety__token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Bitfield_variety> ::= <BfSign>-Opt <Nat>
<BfSign> ::= <Bool>
<BfSign> ::= Signed
<BfSign> ::= Unsigned
</programlisting>
This expands to bfvar_bits. The empty default on the sign is
Signed.</para>
</sect2>
<sect2 id="S20">
<title>Bool</title>
<para>
<programlisting>
<Bool> ::= BOOL ? ( <Exp> , <Bool>, <Bool>)
<Bool> ::= <bool_constructor> < ( <constructor_param>-List ) >-Opt
<Bool> ::= <bool_token> < [ <token_param>-List ] >-Opt
</programlisting>
There are no expansions of <Bool> other than the standard
ones.</para>
</sect2>
<sect2 id="S21">
<title>Error_treatment</title>
<para>
<programlisting>
<Error_treatment> ::= ERROR_TREATMENT ?
( <Exp> , <Error_treatment>, <Error_treatment>)
<Error_treatment> ::= <error_treatment_constructor> < ( <constructor_param>-List ) >-Opt
<Error_treatment> ::= <error_treatment__token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Error_treatment> ::= <Label>
</programlisting>
This gives an error_jump to the label.
<programlisting>
<Error_treatment> ::= [ <Error_code>-List]
<Error_code> ::= overflow
<Error_code> ::= nil_access
<Error_code> ::= stack_overflow
</programlisting>
Produces trap with the <Error_code>s as arguments.</para>
</sect2>
<sect2 id="S22">
<title>xp</title>
<para>
<programlisting>
<Exp> ::= <ExpTerm>
<Exp> ::= <ExpTerm> <BinaryOp> <ExpTerm>
</programlisting>
The <BinaryOp>s include the arithmetic, offset, logical
operators and assignment and are given in table 1. In this
expansion, any error_treatments are taken to be wrap.</para>
<table frame="all">
<tgroup cols="4" colsep="1" rowsep="1">
<thead>
<row>
<entry><BinaryOp></entry>
<entry>TDF constructor</entry>
<entry><BinaryOp></entry>
<entry>TDF constructor</entry>
</row>
</thead>
<tbody>
<row>
<entry>And</entry>
<entry>and</entry>
<entry>Or</entry>
<entry>or</entry>
</row>
<row>
<entry>Xor</entry>
<entry>xor</entry>
<entry>*+.</entry>
<entry>add_to_ptr</entry>
</row>
<row>
<entry>*-*</entry>
<entry>subtract_ptrs</entry>
<entry>.*</entry>
<entry>offset_mult</entry>
</row>
<row>
<entry>.+.</entry>
<entry>offset_add</entry>
<entry>.-.</entry>
<entry>offset_subtract</entry>
</row>
<row>
<entry>./</entry>
<entry>offset_div_by_int</entry>
<entry>./.</entry>
<entry>offset_div</entry>
</row>
<row>
<entry>.max.</entry>
<entry>offset_max</entry>
<entry>%</entry>
<entry>rem2</entry>
</row>
<row>
<entry>%1</entry>
<entry>rem1</entry>
<entry>*</entry>
<entry>mult</entry>
</row>
<row>
<entry>+</entry>
<entry>plus</entry>
<entry>-</entry>
<entry>minus</entry>
</row>
<row>
<entry>/</entry>
<entry>div2</entry>
<entry>/1</entry>
<entry>div1</entry>
</row>
<row>
<entry><<</entry>
<entry>shift_left</entry>
<entry>>></entry>
<entry>shift_right</entry>
</row>
<row>
<entry>F*</entry>
<entry>floating_mult</entry>
<entry>F+</entry>
<entry>floating_plus</entry>
</row>
<row>
<entry>F-</entry>
<entry>floating_minus</entry>
<entry>F/</entry>
<entry>floating_div</entry>
</row>
<row>
<entry>=</entry>
<entry>assign</entry>
</row>
</tbody>
</tgroup>
</table>
<para>The names like *+. (i.e. add_to_ptr) do have a certain logic;
the * indicates that the left operand must be a pointer expression
and the. that the other is an offset</para>
<para>The further expansions of <Exp> are all
<ExpTerm>s</para>
<sect3 id="S23">
<title>ExpTerm</title>
<para>
<programlisting>
<ExpTerm> ::= EXP ? ( <Exp> , <Exp>, <Exp>)
<ExpTerm> ::= <exp_constructor> < ( <constructor_param>-List ) >-Opt
<ExpTerm> ::= <exp_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<ExpTerm> ::= <ClosedExp>
</programlisting>
For <ClosedExp>, see <link linkend="S36">section 3.3</link>.
<programlisting>
<ExpTerm> ::= ( <Exp> )
<ExpTerm> ::= - ( <Exp> )
</programlisting>
The negate constructor.
<programlisting>
<ExpTerm> ::= Sizeof ( <Shape> )
</programlisting>
This produces the EXP OFFSET for an index multiplier for arrays of
<Shape>. It is the shape_offset of <Shape> padded up
to its alignment.
<programlisting>
<ExpTerm> ::= <Tag>
</programlisting>
This produces an obtain_tag.
<programlisting>
<ExpTerm> ::= * <ident>
</programlisting>
The <ident> must have been declared as a variable TAG and
the construction produces a contents operation with its declared
SHAPE.
<programlisting>
<ExpTerm> ::= * ( <Shape> ) <ExpTerm>
</programlisting>
This produces a contents operation with the given <Shape>.
<programlisting>
<ExpTerm> ::= <Assertion>
</programlisting>
For <Assertion>, see <link linkend="S37">section 3.3.1</link>
<programlisting>
<ExpTerm> ::= Case <Exp> ( <RangeDest>-List )
<RangeDest> ::= <Signed_Nat> < : <Signed_Nat> >-Opt -> <Label>
</programlisting>
This produces a case operation.
<programlisting>
<ExpTerm> ::= Cons [ <Exp> ] ( < <Offset> : <Exp> >-List )
<Offset> ::= <Exp>
</programlisting>
This produces a make_compound with the [ <Exp> ] as the size
and fields given by < <Offset> : <Exp> >-List.
<programlisting>
<ExpTerm> ::= [ <Variety> ] <ExpTerm>
</programlisting>
This produces a change_variety with a wrap error_treatment.
<programlisting>
<ExpTerm> ::= <Signed_Nat> ( <Variety> )
</programlisting>
This produces a make_int of the <Signed_Nat> with the given
variety.
<programlisting>
<ExpTerm> ::= <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
<ExpTerm> ::= - <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
</programlisting>
Produces a make_floating.
<programlisting>
<ExpTerm> ::= <ProcVal> [ <Shape> ] ( <Exp>-List-Opt < Varpar <Exp> >-Opt)
<ProcVal> ::= <Tag>
<ProcVal> ::= ( <Exp> )
</programlisting>
Produces an apply_proc with the given parameters returning the
given <Shape>.
<programlisting>
<ExpTerm> ::= <ProcVal> [ <Shape> ]
[ <Act_Callers>-Opt ; <Act_Callees>-Opt <; <Postlude>>-Opt ]
<ProcProps>-Opt
<Act_Callers> ::= <<Exp> <: <ident>>-Opt>-List <...>-Opt
<Act_Callees> ::= <Exp>-List <...>-Opt
<Act_Callees> ::= Dynamic ( <Exp> , <Exp> ) <...>-Opt
<Act_Callees> ::= Same
<Postlude> ::= <Exp>
</programlisting>
Produces an apply_general_proc with the actual caller parameters
given by <Act_Callers> and the calle parameters given by
<Act_Callees>; the <...> option indicates that the
procedure is expecting a variable number of parameters. Any
<ident>s introduced in <Act_Callers> are in scope in
<Postlude>.
<programlisting>
<Exp> ::= <ProcVal> Tail_call [ <Act_Callees>-Opt ]
</programlisting>
Produces a tail_call with the callee parameters given and same
caller parameters as those of the calling procedure.
<programlisting>
<ExpTerm> ::= Proc <Proc_defn>
</programlisting>
Produces a make_proc. For <Proc_defn>, see
<link linkend="S14">section 3.1.7</link> <programlisting>
<ExpTerm> ::= <String> ( <Variety> )
</programlisting>
Produces a make_nof_int of the given variety.
<programlisting>
<ExpTerm> ::= # <String>
</programlisting>
This produces a TDF fail_installer; this construction is useful
for narrowing down SHAPE errors detected by the translator.</para>
</sect3>
</sect2>
<sect2 id="S24">
<title>Floating_variety</title>
<para>
<programlisting>
<Floating_variety> ::= FLOATING_VARIETY ?
( <Exp> , <Floating_variety>, <Floating_variety>)
<Floating_variety> ::= <floating_variety_constructor> < ( <constructor_param>-List ) >-Opt
<Floating_variety> ::= <floating_variety__token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard constructions.
<programlisting>
<Floating_variety> ::= Float
</programlisting>
An IEEE 32 bit floating variety.
<programlisting>
<Floating_variety> ::= Double
</programlisting>
An IEEE 64 bit floating variety.</para>
</sect2>
<sect2 id="S25">
<title>Label</title>
<para>
<programlisting>
<Label> ::= <label_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard token application.
<programlisting>
<Label> ::= <ident>
</programlisting>
The <ident> will be declared as a LABEL, whose scope is the
current procedure.</para>
</sect2>
<sect2 id="S26">
<title>Nat</title>
<para>
<programlisting>
<Nat> ::= NAT ? ( <Exp> , <Nat>, <Nat>)
<Nat> ::= <nat_constructor> < ( <constructor_param>-List ) >-Opt
<Nat> ::= <nat_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Nat> ::= <integer_denotation>
</programlisting>
Produces a make_nat on the integer
<programlisting>
<Nat> ::= <character>
</programlisting>
Produces a make_nat on the ASCII value of the character.</para>
</sect2>
<sect2 id="S27">
<title>Ntest</title>
<para>
<programlisting>
<Ntest> ::= NTEST ? ( <Exp> , <Ntest>, <Ntest>)
<Ntest> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt
<Ntest> ::= <ntest_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Ntest> ::= !<
</programlisting>
Produces not_less_than.
<programlisting>
<Ntest> ::= !<=
</programlisting>
Produces not_less_than_or_equal.
<programlisting>
<Ntest> ::= !=
</programlisting>
Produces not_equal.
<programlisting>
<Ntest> ::= !>
</programlisting>
Produces not_greater_than.
<programlisting>
<Ntest> ::= !>=
</programlisting>
Produces not_greater_than_or_equal.
<programlisting>
<Ntest> ::= !Comparable
</programlisting>
Produces not_comparable.
<programlisting>
<Ntest> ::= <
</programlisting>
Produces less_than.
<programlisting>
<Ntest> ::= <=
</programlisting>
Produces less_than_or_equal.
<programlisting>
<Ntest> ::= ==
</programlisting>
Produces equal.
<programlisting>
<Ntest> ::= >
</programlisting>
Produces greater_than.
<programlisting>
<Ntest> ::= >=
</programlisting>
Produces greater_than_or_equal.</para>
</sect2>
<sect2 id="S28">
<title>Rounding_mode</title>
<para>
<programlisting>
<Rounding_mode> ::= ROUNDING_MODE?
( <Exp> , <Rounding_mode>, <Rounding_mode>)
<Rounding_mode> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt
<Rounding_mode> ::= <ntest_token> < [ <token_param>-List ] >-Opt
</programlisting>
There are no constructions for <Rounding_mode> other than
the standard ones.</para>
</sect2>
<sect2 id="S29">
<title>Shape</title>
<para>
<programlisting>
<Shape> ::= SHAPE ? ( <Exp> , <Shape>, <Shape>)
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Shape> ::= Float
</programlisting>
The shape for an IEEE 32 bit float.
<programlisting>
<Shape> ::= Double
</programlisting>
The shape for an IEEE 64 bit float.
<programlisting>
<Shape> ::= <Sign>-Opt Int
<Sign> ::= Signed
<Sign> ::= Unsigned
</programlisting>
The shape for a 32 bit signed or unsigned integer. The default is
signed.
<programlisting>
<Shape> ::= <Sign>-Opt Long
</programlisting>
The shape for a 32 bit signed or unsigned integer.
<programlisting>
<Shape> ::= <Sign>-Opt Short
</programlisting>
The shape for a 16 bit signed or unsigned integer.
<programlisting>
<Shape> ::= <Sign>-Opt Char
</programlisting>
The shape for a 8 bit signed or unsigned integer.
<programlisting>
<Shape> ::= Ptr <Shape>
</programlisting>
The SHAPE pointer(alignment(<Shape>)).</para>
</sect2>
<sect2 id="S30">
<title>Signed_Nat</title>
<para>
<programlisting>
<Signed_Nat> ::= SIGNED_NAT ? ( <Exp> , <Signed_Nat>, <Signed_Nat>)
<Signed_Nat> ::= <signed_nat_constructor> < ( <constructor_param>-List ) >-Opt
<Signed_Nat> ::= <signed_nat_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Signed_Nat> ::= <integer_denotation>
<Signed_Nat> ::= - <integer_denotation>
</programlisting>
This produces a make_signed_nat on the integer value.
<programlisting>
<Signed_Nat> ::= <character>
<Signed_Nat> ::= - <character>
</programlisting>
This produces a make_signed_nat on the ASCII value of the
character.
<programlisting>
<Signed_Nat> ::= LINE
</programlisting>
This produces a make_signed_nat on the current line number of the
file being compiled - useful for writing test programs.
<programlisting>
<Signed_Nat> ::= + <Nat>
<Signed_Nat> ::= - <Nat>
</programlisting>
This produces an appropriately signed <Signed_Nat> from a
<Nat>.</para>
</sect2>
<sect2 id="S31">
<title>String</title>
<para>
<programlisting>
<String> ::= STRING? ( <Exp> , <String>, <String>)
<String> ::= <string_constructor> < ( <constructor_param>-List ) >-Opt
<String> ::= <string_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions
<programlisting>
<String> ::= <string>
</programlisting>
Produces a make_string.</para>
</sect2>
<sect2 id="S32">
<title>Tag</title>
<para>
<programlisting>
<Tag> ::= <tag_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard token application.
<programlisting>
<Tag> ::= <ident>
</programlisting>
This gives an obtain_tag; the <ident> must been declared as
a TAG either globally or locally.</para>
</sect2>
<sect2 id="S33">
<title>Token</title>
<para>TOKEN is rather a limited first-class sort. There is no
explicit construction given for token_apply_token, since the only
place where it can occur is in an expansion of a token parameter
of another token; here it is produced implicitly. The only place
where <Token> is expanded is in an actual TOKEN parameter of
a token application; other uses (e.g. as in <shape_token>)
are always <ident>s.
<programlisting>
<Token> ::= <ident>
</programlisting>
The <ident> must have been declarered by a <Tokdec> or
<Tokdec> or is a formal parameter of TOKEN.
<programlisting>
<Token> ::= Use <Tok_Defn>
</programlisting>
This produces a use_tokdef. For <Tok_Defn> see
<link linkend="S9">section 3.1.2</link>. The critical use of this
construction is to provide an actual TOKEN parameter to a token
application where the <Tok_Defn> contains uses of tags or
labels local to a procedure.</para>
</sect2>
<sect2 id="S34">
<title>Transfer_mode</title>
<para>
<programlisting>
<Transfer_mode> ::= TRANSFER_MODE ? ( <Exp> , <Transfer_mode>, <Transfer_mode>)
<Transfer_mode> ::= <transfer_mode_constructor> < ( <constructor_param>-List ) >-Opt
<Transfer_mode> ::= <transfer_mode_token> < [ <token_param>-List ] >-Opt
</programlisting>
There are no expansions for <Transfer_mode> other than the
standard expansions.</para>
</sect2>
<sect2 id="S35">
<title>Variety</title>
<para>
<programlisting>
<Variety> ::= VARIETY ? ( <Exp> , <Variety>, <Variety>)
<Variety> ::= <variety_constructor> < ( <constructor_param>-List ) >-Opt
<Variety> ::= <variety_token> < [ <token_param>-List ] >-Opt
</programlisting>
The standard expansions.
<programlisting>
<Variety> ::= <Signed_Nat> : <Signed_Nat>
</programlisting>
This produces var_limits.
<programlisting>
<Variety> ::= <Sign>-Opt Int
<Variety> ::= <Sign>-Opt Long
<Variety> ::= <Sign>-Opt Short
<Variety> ::= <Sign>-Opt Char
</programlisting>
This produces the variety of the appropriate integer shape.</para>
</sect2>
</sect1>
<sect1 id="S36">
<title>Control structure and local declarations</title>
<para>The control and declaration structure is given by
<ClosedExp>:
<programlisting>
<ClosedExp> ::= { <ExpSeq> }
<ExpSeq> ::= <Exp>-Opt
<ExpSeq> ::= <ExpSeq> ; <Exp>-Opt
</programlisting>
This produces a TDF sequence if there is more than one
<Exp>-Opt; if there is only one it is simply the production
for <Exp>-Opt; any empty <Exp>-Opt produce make_top.
<programlisting>
<ClosedExp> ::= <ConditionalExp>
<ClosedExp> ::= <RepeatExp>
<ClosedExp> ::= <LabelledExp>
<ClosedExp> ::= <Local_Defn>
</programlisting>
The effect of these, together with the expansion of
<Assertion> is given below.</para>
<sect2 id="S37">
<title>ConditionalExp and Assertion</title>
<para>
<programlisting>
<ConditionalExp> ::= ? { <ExpSeq> | <LabelSetting>-Opt <ExpSeq> }
<LabelSetting> ::= : <Label> :
</programlisting>
This produces a TDF conditional. The scope of a LABEL
<ident> which may be introduced by <Label> is the
first <ExpSeq>. A branch to the second half of the
conditional will usually be made by the failure of an
<Assertion> ( ie a TDF _test) in the first half.
<programlisting>
<Assertion> ::= <Query> ( <Exp> <Ntest> <Exp> <FailDest>-Opt )
<Query> ::= ?
</programlisting>
The assertion will be translated as an integer_test
<programlisting>
<Query> ::= F?
</programlisting>
The assertion will be translated as a floating_test with a wrap
error_treatment.
<programlisting>
<Query> ::= *?
</programlisting>
The assertion will be translated as a pointer_test.
<programlisting>
<Query> ::=.?
</programlisting>
The assertion will be translated as an offset_test.
<programlisting>
<Query> ::= P?
</programlisting>
The assertion will be translated as a proc_test.
<programlisting>
<FailDest> ::= | <Label>
</programlisting>
The <Assertion> will produce the appropriate _test on its
component <Exp>s. If the test fails, then control will pass
to the <FailDest>-Opt. If <FailDest>-Opt is not empty,
this is the <Label>. Otherwise, the <Assertion> must
be in the immediate context of a <ConditionalExp> or
<RepeatExp> with an empty <LabelSetting>-Opt; in which
case this is treated as an anonymous label and control passes to
there. For example, the following <Conditional> delivers the
maximum of two integers:
<programlisting>
?{ ?(a >= b); a | b }
</programlisting>
This is equivalent to:
<programlisting>
?{ ?(a >= b | L ); a | :L: b }
</programlisting>
without the hassle of having to invent the LABEL name, L.</para>
</sect2>
<sect2 id="S38">
<title>RepeatExp</title>
<para>
<programlisting>
<RepeatExp> ::= Rep <Starter>-Opt { <LabelSetting>-Opt <ExpSeq> }
<Starter> = ( <ExpSeq> )
</programlisting>
This produces a TDF repeat. The loop will usually repeat by an
<Assertion> failing to the <LabelSetting>-Opt; an
empty <LabelSetting>-Opt will follow the same conventions as
one in a <Conditional>. An empty <Starter>-Opt will
produce make_top.</para>
</sect2>
<sect2 id="S39">
<title>LabelledExp</title>
<para>
<programlisting>
<LabelledExp> ::= Labelled { <ExpSeq> <Places> }
<Places> ::= <Place>
<Places> ::= <Places> <Place>
<Place> ::= | : <Label> : <ExpSeq>
</programlisting>
This produces a TDF labelled with the obvious parameters. The
scope of any LABEL <idents> introduced by the <Label>s
is the <LabelledExp>.</para>
</sect2>
<sect2 id="S40">
<title>Local_Defn</title>
<para>A <Local_Defn> introduces an <ident> as a TAG for
the scope of the component <ClosedExp>. Any containing an
<Access> visible is also available globally - however it
will only make sense in the constructor env_offset.
<programlisting>
<Local_Defn> ::= Var <ident> <Access>-Opt <VarInit> <ClosedExp>
<VarInit> ::= = <Exp>
</programlisting>
This <Local_Defn> produces a TDF variable with the obvious
parameters.
<programlisting>
<Local_Defn> ::= Var <ident> <Access>-Opt : <Shape> <VarInit>-Opt <ClosedExp>
</programlisting>
Also a TDF variable. An empty <VarInit>-Opt gives
make_value(<Shape>) as the initialisation to the variable.
Using this form of variable definition also has the advantage of
allowing one to use the simple form of the contents operation (*
in <link linkend="S22">section 3.2.7</link>).
<programlisting>
<Local_Defn> ::= Let <ident> <Access>-Opt = <Exp> <ClosedExp>
</programlisting>
This produces a TDF identify with the obvious parameters.</para>
</sect2>
</sect1>
</chapter>
<chapter id="S41">
<title>Example PL_TDF programs</title>
<sect1 id="S42">
<title>Sieve of Erastothenes</title>
<para>
<programlisting>
/* Print out the primes less than 10000 */
String s1 = "%d\t"; /* good strings for printf */
String s2 = "\n";
Var n: nof(10000, Char); /* will contain1 for prime; 0 for composite */
Tokdef N = [ind:EXP]EXP n *+. (Sizeof(Char) .* ind);
/* Token delivering pointer to element of n */
Iddec printf : proc; /* definition provided by ansi library */
Proc main = top ()
Var i:Int
Var j:Int
{ Rep (i = 2(Int))
{ /* set i-th element of n to 1 */
N[* i] = 1(Char);
i = (* i + 1(Int));
?(* i >= 10000(Int)) /* NB assertion fails to continue loop */
}
Rep (i = 2(Int) )
{
?{ ?( *(Char)N[* i] == 1(Char));
/* if its a prime ... */
Rep ( j = (* i + * i) )
{ /*... wipe out composites */
N[* j] = 0(Char);
j = (* j + * i);
?(* j >= 10000(Int))
}
| make_top
};
i = (* i + 1(Int));
?(* i >= 100(Int))
};
Rep (i = 2(Int); j = 0(Int) )
{ ?{ ?( *(Char)N[* i] == 1(Char));
/* if it's a prime, print it */
printf[top](s1, * i);
j = (* j + 1(Int));
?{ ?( * j == 5(Int));
/* print new line */
printf[top](s2);
j = 0(Int)
| make_top
}
| make_top
};
i = (* i + 1(Int));
?(* i >= 10000(Int))
};
return(make_top)
};
Keep (main) /* main will be an external name; so will printf since it is not defined */
</programlisting>
</para>
</sect1>
<sect1 id="S43">
<title>Example with structures</title>
<para>
<programlisting>
Struct C (re:Double, im:Double);
/* define TOKENs : C as a SHAPE for complex, with field offsets .re and .im
and selectors re and im */
Iddec printf:proc;
Proc addC = C (lv:C, rv:C) /* add two complex numbers */
Let l = * lv
Let r = * rv
{ return( Cons[shape_offset(C)] ( .re: re[l] F+ re[r], .im: im[l] F+ im[r]) ) } ;
String s1 = "Ans = (%g, %g)\n";
Proc main = top()
Let x = Cons[shape_offset(C)] (.re: 1.0(Double), .im:2.0(Double))
Let y = Cons[shape_offset(C)] (.re: 3.0(Double), .im:4.0(Double))
Let z = addC[C](x,y)
{ printf[top](s1, re[z], im[z]);
/* prints out "Ans = (4, 6)" */
return(make_top)
};
Keep(main)
</programlisting>
</para>
</sect1>
<sect1 id="S44">
<title>Test for case</title>
<para>
<programlisting>
Iddec printf:proc;
String s1 = "%d is not in [%d,%d]\n";
String s2 = "%d OK\n";
Proc test = top(i:Int, l:Int, u:Int) /* report whether l<=i<=u */
?{ ?(* i >= * l); ?(* i <= * u);
printf[top](s2, * i);
return(make_top)
| printf[top](s1, * i, * l, * u);
return(make_top)
};
String s3 = "ERROR with %d\n";
Proc main = top() /* check to see that case is working */
Var i:Int = 0(Int)
Rep {
Labelled {
Case * i (0 -> l0, 1 -> l1, 2:3 -> l2, 4:10000 -> l3)
| :l0: test[top](* i, 0(Int), 0(Int))
| :l1: test[top](* i, 1(Int), 1(Int))
| :l2: test[top](* i, 2(Int), 3(Int))
| :l3: printf[top](s3, * i)
};
i = (* i + 1(Int));
?(* i > 3(Int));
return(make_top)
};
Keep (main, test)
</programlisting>
</para>
</sect1>
<sect1 id="S45">
<title>Example of use of high-order TOKENs</title>
<para>
<programlisting>
Tokdef IF = [ boolexp:TOKEN[LABEL]EXP, thenpt:EXP, elsept:EXP] EXP
?{ boolexp[lab]; thenpt | :lab: elsept };
/* IF is a TOKEN which can be used to mirror a standard if ... then ... else
construction; the boolexp is a formal TOKEN with a LABEL parameter
which is jumped to if the boolean is false */
Iddec printf: proc;
String cs = "Correct\n";
String ws = "Wrong\n";
Proc main = top()
Var i:Int = 0(Int)
{
IF[ Use [l:LABEL]EXP ?(* i == 0(Int) | l), printf[top](cs), printf[top](ws) ];
/* in other words if (i==0) printf("Correct") else printf("Wrong") */
IF[ Use [l:LABEL]EXP ?(* i != 0(Int) | l), printf[top](ws), printf[top](cs) ];
i = IF[ Use [l:LABEL]EXP ?(* i != 0(Int) | l), 2(Int), 3(Int)];
IF[ Use [l:LABEL]EXP ?(* i == 3(Int) | l), printf[top](cs), printf[top](ws) ];
return(make_top)
};
Keep (main)
</programlisting>
</para>
</sect1>
<sect1 id="S46">
<title>A test for long jumps</title>
<para>
<programlisting>
Iddec printf:proc;
Proc f = bottom(env:pointer(frame_alignment), lab:pointer(code_alignment) )
{
long_jump(* env, * lab)
};
String s1 = "Should not reach here\n";
String s2 = "long-jump OK\n";
Proc main = top()
Labelled{
f[bottom](current_env, make_local_lv(l));
printf[top](s1); /* should never reach here */
return(make_top)
| :l:
printf[top](s2);
return(make_top)
};
Keep (main)
</programlisting>
</para>
</sect1>
</chapter>
<chapter>
<title>Use of the PL_TDF compiler</title>
<para>Conventionally, PL_TDF programs are held in normal text files with
suffix .pl. The PL_TDF compiler is invoked by:
<programlisting>
pl [-v] [-Iinclude_path ...] [-g] [-V ] infile.pl outfile.j
</programlisting>
This compiles infile.pl to TDF in outfile.j. This file can be linked and
loaded just as any other .j file using tcc.</para>
<para>The -v option will produce a cut-down pretty print of the TDF for
the definitions and declarations of the tags, tokens and al_tags of
the program on the standard output.</para>
<para>The -I options will defines the paths for any #include
pre-processing directives in the text.</para>
<para>The -g option will put line number information into the
TDF.</para>
<para>The -V option will print version information of both pl and the
TDF it produces.</para>
<para>Compile-time error reporting is rather rudimentary and error
recovery non-existent. Only the first error found will be reported on
the standard error channel. This will give some indication of the type
of error, together with the text line number and a print-out of the
line, marking the place within the line where the error was
detected.</para>
<para>Errors which can only be detected at translate-time are much more
difficult to correct. These are usually shape or alignment errors,
particularly in the construction of offsets. Try compiling and
translating with the -g option. On the error, the translator will
output the source filename and an approximate line-number
corresponding to the position of the error in the PL_TDF.</para>
<para>Translating with the -g option may sometimes give warning messages
from the system assembler being used; some assemblers object to being
given line number information in anything else but the .text segment
of the program. The main intention of the -g option is to detect and
correct errors errors thrown up by the translators and not for
run-time de-bugging, so do not regard a warning like this as a bug in
the system.</para>
</chapter>
</book>