Rev 6 | 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>TenDRA Suite Purpose Overview</title>
<corpauthor>The TenDRA Project</corpauthor>
<author>
<firstname>Kate</firstname>
<surname>Flavel</surname>
</author>
<authorinitials>KF</authorinitials>
<pubdate>2006</pubdate>
<copyright>
<year>2006</year>
<holder>The TenDRA Project</holder>
</copyright>
<copyright>
<!--
I'm assuming this is copyright to Rob himself, as he
says his TenDRA homepage (from which this text is
taken) is unofficial.
-->
<!-- Crown Copyright (c) 1998 -->
<year>1998</year>
<holder>Rob Andrews</holder>
</copyright>
</bookinfo>
<chapter id="what-is-tdf">
<title>What is TDF?</title>
<para>TDF (standing for TenDRA Distribution Format) is the compiler
intermediate language, which lies at the heart of the TenDRA technology.
Unlike most intermediate languages, which tend to be abstractions of
assembler languages, TDF is an abstraction of high level languages. The
current release is based on TDF Issue 4.0, with experimental extensions
to handle debugging in languages such as C++ and Ada (these extensions
are not used by default).</para>
<para>The <ulink url="spec.html">TDF Specification (Issue 4.0)</ulink>
gives a technical description of the TDF language. This is supplemented
by the <ulink url="diagnostic.html">TDF Diagnostic Extension
Specification (Issue 3.0)</ulink>. This is an extension to the core TDF
specification, which describes how information sufficient to allow for
the debugging of C programs can be embedded into a TDF capsule (it is
this that the experimental extensions mentioned above are intended to
replace).</para>
<para>The companion document, the <ulink url="register.html">TDF token
register</ulink>, describes the globally reserved, 'standard
tokens'.</para>
<para>The <ulink url="guide.html">Guide to the TDF specification</ulink>
gives an overview and commentary on the TDF language, explaining some of
the more difficult concepts.</para>
<para>For those who know a bit of history, TDF was the technology adopted
by OSF as their ANDF (Architecture Neutral Distribution Format), and TDF
Issue 4.0 (Revision 1) is the base document for The Open Group XANDF
standard. Thus the terms TDF, ANDF and XANDF are largely synonymous; TDF
is used in documentation since it is the term closest to our
hearts.</para>
</chapter>
<chapter id="what-is-tendra">
<title>What is TenDRA?</title>
<para>TenDRA is the name of the compiler technology built around the TDF
intermediate language. The design and intended uses of TDF have affected
how the TenDRA technology has developed. For example, the original
emphasis of OSF's ANDF concept was on distribution, but this begged the
question about program portablility. The current TenDRA technology is
far more about portability than it is about distribution, although TDF
could still be used as a distribution format.</para>
<para>The rigid enforcement of an interface level between the compiler
front-ends and the compiler back-ends, and the goal of producing target
independent TDF (suitable for distribution) have produced a flexible,
clean compiler technology. It has pulled many of the questions about
program portability into sharp focus in a way that a more conventional
compiler could not.</para>
</chapter>
<chapter id="using-the-tendra-compiler">
<title>Using the TenDRA Compiler</title>
<para>The main user interface to the TenDRA compiler,
<emphasis>tcc</emphasis>, can be used as a direct replacement for the
system compiler, <emphasis>cc</emphasis>. This is described in the
<ulink url="tcc.html"><emphasis>tcc</emphasis> Users'
Guide</ulink>.</para>
<para>There is an alternative user interface, <emphasis>tchk</emphasis>,
which just applies the static program checks and disables code
generation. Thus <emphasis>tchk</emphasis> corresponds to
<emphasis>lint</emphasis> in the same way that <emphasis>tcc</emphasis>
corresponds to <emphasis>cc</emphasis>.</para>
<para>The chief difference between <emphasis>tcc</emphasis> and other
compilers is it the degree of preciseness it requires in specifying the
compilation environment. This environment consists of two, largely
orthogonal, components: the language checks to be applied, and the API
to be checked against. For example, the <code>-Xc</code> option
specifies ISO C with no extensions and no extra checks, the
<code>-Xa</code> option specifies ISO C with common extensions, and
<code>-Xs</code> specifies ISO C with no extensions and lots of extra
checks. Similarly <code>-Yansi</code> specifies the ISO C API (excluding
Amendment 1), <code>-Yposix</code> specifies the POSIX 1003.1 API etc.
It is also possible to make <emphasis>tcc</emphasis> use the system
headers on the host machine by the use of the <code>-Ysystem</code>
option. The <code>-Yc++</code> option is required to enable the C++
facilities. The default mode is equivalent to <code>-Xc
-Yansi.</code></para>
<para>How to configure the C compiler checks is described in more detail
in the <ulink url="tdfc.html">C Checker Reference Manual</ulink>. The
extra checks available in C++ are described in the
<ulink url="tcpplus.html">C++ producer guide</ulink>.</para>
</chapter>
<chapter id="tdf-producers">
<title>TDF Producers</title>
<para>A tool which compiles a high-level language to TDF, is called a
<emphasis>producer</emphasis>. The TenDRA software contains producers
for the C and C++ languages. The original TenDRA C producer
(<emphasis>tdfc</emphasis>) has now been superseded by a new C producer
(<emphasis>tdfc2</emphasis>) based on the C++ producer
(<emphasis>tcpplus</emphasis>).</para>
<para>The design of both producers has been guided by the goal of trying
to ensure program portability by means of static program analysis. Some
thoughts on this subject are set out in the document
<ulink url="port.html">TDF and portability</ulink>.</para>
<para>The first component of this is by ensuring that the language
implemented by the producer accurately reflects the corresponding
language standard (ISO C, including Amendment 1, or the draft ISO C++
standard). The producers both include references to the standards
documents within their error messages, so that a specific error can be
tied to a specific clause within the standard. The producers have been
tested using both the Plum Hall and Perennial C and C++ compiler
validation suites.</para>
<para>The C++ producer implements most of the language sections of the
November 1997 draft ISO C++ standard. The known problem areas
are:</para>
<itemizedlist>
<listitem>
<para>Automatic inter-module instantiation of templates is not yet
fully implemented.</para>
</listitem>
<listitem>
<para>The current implementation of exception handling is not optimal
with respect to performance.</para>
</listitem>
<listitem>
<para>Temporaries are not always destroyed in precisely the right
place.</para>
</listitem>
<listitem>
<para>Partially constructed objects are not destroyed properly.</para>
</listitem>
<listitem>
<para>The visibility of <emphasis>friend</emphasis> functions is not
right.</para>
</listitem>
</itemizedlist>
<para>(<emphasis><new></emphasis>,
<emphasis><typeinfo></emphasis> and
<emphasis><exception></emphasis>) have been implemented. If a
complete implementation of the standard C++ library is required, it must
be obtained from elsewhere. See the
<ulink url="tcpplus.html">C++ producer guide</ulink> for more
details.</para>
</chapter>
<chapter id="tdf-installers">
<title>TDF Installers</title>
<para>A tool which compiles TDF to a machine language, is called an
<emphasis>installer</emphasis>. TDF installers for a number of Unix
systems and processors are included within the release (see the list of
<ulink url="install.html#platforms">supported platforms</ulink>). Each
installer consists of code from three levels:</para>
<orderedlist>
<listitem>
<para>Code which is common to all installers. A large portion of each
installer is derived from a common section, which reads the input
TDF capsule and applies various TDF -> TDF transformations to
optimise the code. Each installer has a configuration file which
indicates which of these transformations are appropriate to its
particular processor.</para>
</listitem>
<listitem>
<para>Code which is specific to a particular processor. Each installer
also has some processor-specific code, which applies optimisations
and other transformations, which are too tied to a particular
processor to warrant inclusion in the common section. This section
also includes register allocation.</para>
</listitem>
<listitem>
<para>Code which is specific to a particular processor/operating
system pair. Even within the installers for a single processor,
there may be differences between different operating systems. These
differences are usually cosmetic, such as the precise assembler
format etc. of reliability and performance tuning, due to the
differing priorities in building up an installer base. The Intel
and SPARC installers are the most reliable and have been subject
to the most performance tuning.</para>
</listitem>
</orderedlist>
<para>All the installers fully support the C subset of TDF (i.e. code
generated by the C producer). The Mips/Ultrix installer does not support
the <emphasis>initial_value</emphasis> construct (used in dynamic
initialisation), but otherwise all the installers fully support the C++
subset. The Intel and SPARC installers fully support the entire TDF
specification, as checked by the OSF AVS (ANDF Validation Suite).</para>
</chapter>
<chapter id="tdf-tools">
<title>TDF Tools</title>
<para>There are various tools included within the software for viewing,
generating and transforming TDF. <emphasis>tspec</emphasis> excepted,
the use of these components is integrated into the user interface,
<emphasis>tcc</emphasis>, but they may also be called directly.</para>
<!--
We should probably use glossary collections here, instead.
Currently the "See Also" links will render missing; those
aren't appropiate for this document, though. Is there a way
to prevent those from being output entirely?
-->
<glosslist>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/tspec.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/tld.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/disp.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/tnc.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/tpl.xml"/>
</glosslist>
</chapter>
<chapter id="compiler-writing-tools">
<title>Compiler Writing Tools</title>
<para>A number of compiler writing tools, which were used in the
development of the TenDRA compiler technology are also bundled with the
TenDRA software release. These include the following:</para>
<glosslist>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/sid.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/calculus.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
href="../../glossary/entries/make_tdf.xml"/>
<!-- TODO make_err, lexi -->
</glosslist>
</chapter>
</book>