Rev 2 | Blame | Compare with Previous | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>Introduction</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<H1><A NAME=S3>TDF Specification, Issue 4.0</A></H1>
<H3>January 1998</H3>
<A HREF="spec5.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
<A HREF="spec1.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="spec1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<A HREF="spec12.html"><IMG SRC="../images/index.gif" ALT="document index"></A>
<P>
<HR>
<H1>1. Introduction</H1>
TDF is a porting technology and, as a result, it is a central part
of a shrink-wrapping, distribution and installation technology. TDF
has been chosen by the Open Software Foundation as the basis of its
Architecture Neutral Distribution Format. It was developed by the
United Kingdom's Defence Research Agency (DRA). TDF is not UNIX specific,
although most of the implementation has been done on UNIX.
<P>
Software vendors, when they port their programs to several platforms,
usually wish to take advantage of the particular features of each
platform. That is, they wish the versions of their programs on each
platform to be functionally equivalent, but not necessarily algorithmically
identical. TDF is intended for porting in this sense. It is designed
so that a program in its TDF form can be systematically modified when
it arrives at the target platform to achieve the intended functionality
and to use the algorithms and data structures which are appropriate
and efficient for the target machine. A fully efficient program, specialised
to each target, is a necessity if independent software vendors are
to take-up a porting technology.
<P>
These modifications are systematic because, on the source machine,
programmers work with generalised declarations of the APIs they are
using. The declarations express the requirements of the APIs without
giving their implementation. The declarations are specified in terms
of TDF's "tokens", and the TDF which is produced contains
uses of these tokens. On each target machine the tokens are used as
the basis for suitable substitutions and alterations.
<P>
Using TDF for porting places extra requirements on software vendors
and API designers. Software vendors must write their programs scrupulously
in terms of APIs and nothing more. API designers need to produce an
interface which can be specialised to efficient data structures and
constructions on all relevant machines.
<P>
TDF is neutral with respect to the set of languages which has been
considered. The design of C, C++, Fortran and Pascal is quite conventional,
in the sense that they are sufficiently similar for TDF constructions
to be devised to represent them all. These TDF constructions can be
chosen so that they are, in most cases, close to the language constructions.
Other languages, such as Lisp, are likely to need a few extensions.
To express novel language features TDF will probably have to be more
seriously extended. But the time to do so is when the feature in question
has achieved sufficient stability. Tokens can be used to express the
constructs until the time is right. For example, there is a lack of
consensus about the best constructions for parallel languages, so
that at present TDF would either have to use low level constructions
for parallelism or back what might turn out to be the wrong system.
In other words it is not yet the time to make generalisations for
parallelism as an intrinsic part of TDF.
<P>
TDF is neutral with respect to machine architectures. In designing
TDF, the aim has been to retain the information which is needed to
produce and optimise the machine code, while discarding identifier
and syntactic information. So TDF has constructions which are closely
related to typical language features and it has an abstract model
of memory. We expect that programs expressed in the considered languages
can be translated into code which is as efficient as that produced
by native compilers for those languages.
<P>
Because of these porting features TDF supports shrink-wrapping, distribution
and installation. Installation does not have to be left to the end-user;
the production of executables can be done anywhere in the chain from
software vendor, through dealer and network manager to the end-user.
<P>
This document provides English language specifications for each construct
in the TDF format and some general notes on various aspects of TDF.
It is intended for readers who are aware of the general background
to TDF but require more detailed information.
<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>