| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>Introduction</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<H1><A NAME=S3>TDF Specification, Issue 4.0</A></H1>
|
|
|
8 |
<H3>January 1998</H3>
|
|
|
9 |
<A HREF="spec5.html"><IMG SRC="../images/next.gif" ALT="next section"></A>
|
|
|
10 |
<A HREF="spec1.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
11 |
<A HREF="spec1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
12 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
13 |
</A>
|
|
|
14 |
<A HREF="spec12.html"><IMG SRC="../images/index.gif" ALT="document index"></A>
|
|
|
15 |
<P>
|
|
|
16 |
<HR>
|
|
|
17 |
<H1>1. Introduction</H1>
|
|
|
18 |
TDF is a porting technology and, as a result, it is a central part
|
|
|
19 |
of a shrink-wrapping, distribution and installation technology. TDF
|
|
|
20 |
has been chosen by the Open Software Foundation as the basis of its
|
|
|
21 |
Architecture Neutral Distribution Format. It was developed by the
|
|
|
22 |
United Kingdom's Defence Research Agency (DRA). TDF is not UNIX specific,
|
|
|
23 |
although most of the implementation has been done on UNIX.
|
|
|
24 |
<P>
|
|
|
25 |
Software vendors, when they port their programs to several platforms,
|
|
|
26 |
usually wish to take advantage of the particular features of each
|
|
|
27 |
platform. That is, they wish the versions of their programs on each
|
|
|
28 |
platform to be functionally equivalent, but not necessarily algorithmically
|
|
|
29 |
identical. TDF is intended for porting in this sense. It is designed
|
|
|
30 |
so that a program in its TDF form can be systematically modified when
|
|
|
31 |
it arrives at the target platform to achieve the intended functionality
|
|
|
32 |
and to use the algorithms and data structures which are appropriate
|
|
|
33 |
and efficient for the target machine. A fully efficient program, specialised
|
|
|
34 |
to each target, is a necessity if independent software vendors are
|
|
|
35 |
to take-up a porting technology.
|
|
|
36 |
<P>
|
|
|
37 |
These modifications are systematic because, on the source machine,
|
|
|
38 |
programmers work with generalised declarations of the APIs they are
|
|
|
39 |
using. The declarations express the requirements of the APIs without
|
|
|
40 |
giving their implementation. The declarations are specified in terms
|
|
|
41 |
of TDF's "tokens", and the TDF which is produced contains
|
|
|
42 |
uses of these tokens. On each target machine the tokens are used as
|
|
|
43 |
the basis for suitable substitutions and alterations.
|
|
|
44 |
<P>
|
|
|
45 |
Using TDF for porting places extra requirements on software vendors
|
|
|
46 |
and API designers. Software vendors must write their programs scrupulously
|
|
|
47 |
in terms of APIs and nothing more. API designers need to produce an
|
|
|
48 |
interface which can be specialised to efficient data structures and
|
|
|
49 |
constructions on all relevant machines.
|
|
|
50 |
<P>
|
|
|
51 |
TDF is neutral with respect to the set of languages which has been
|
|
|
52 |
considered. The design of C, C++, Fortran and Pascal is quite conventional,
|
|
|
53 |
in the sense that they are sufficiently similar for TDF constructions
|
|
|
54 |
to be devised to represent them all. These TDF constructions can be
|
|
|
55 |
chosen so that they are, in most cases, close to the language constructions.
|
|
|
56 |
Other languages, such as Lisp, are likely to need a few extensions.
|
|
|
57 |
To express novel language features TDF will probably have to be more
|
|
|
58 |
seriously extended. But the time to do so is when the feature in question
|
|
|
59 |
has achieved sufficient stability. Tokens can be used to express the
|
|
|
60 |
constructs until the time is right. For example, there is a lack of
|
|
|
61 |
consensus about the best constructions for parallel languages, so
|
|
|
62 |
that at present TDF would either have to use low level constructions
|
|
|
63 |
for parallelism or back what might turn out to be the wrong system.
|
|
|
64 |
In other words it is not yet the time to make generalisations for
|
|
|
65 |
parallelism as an intrinsic part of TDF.
|
|
|
66 |
<P>
|
|
|
67 |
TDF is neutral with respect to machine architectures. In designing
|
|
|
68 |
TDF, the aim has been to retain the information which is needed to
|
|
|
69 |
produce and optimise the machine code, while discarding identifier
|
|
|
70 |
and syntactic information. So TDF has constructions which are closely
|
|
|
71 |
related to typical language features and it has an abstract model
|
|
|
72 |
of memory. We expect that programs expressed in the considered languages
|
|
|
73 |
can be translated into code which is as efficient as that produced
|
|
|
74 |
by native compilers for those languages.
|
|
|
75 |
<P>
|
|
|
76 |
Because of these porting features TDF supports shrink-wrapping, distribution
|
|
|
77 |
and installation. Installation does not have to be left to the end-user;
|
|
|
78 |
the production of executables can be done anywhere in the chain from
|
|
|
79 |
software vendor, through dealer and network manager to the end-user.
|
|
|
80 |
<P>
|
|
|
81 |
This document provides English language specifications for each construct
|
|
|
82 |
in the TDF format and some general notes on various aspects of TDF.
|
|
|
83 |
It is intended for readers who are aware of the general background
|
|
|
84 |
to TDF but require more detailed information.
|
|
|
85 |
<P>
|
|
|
86 |
<HR>
|
|
|
87 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
88 |
Copyright © 1998.</I></P>
|
|
|
89 |
</BODY>
|
|
|
90 |
</HTML>
|