1.1. What is TDF?

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).

The TDF Specification gives a technical description of the TDF language. This is supplemented by the TDF Diagnostic Specification. 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).

The companion document, The TDF Token Register, describes the globally reserved, “standard tokens”.

The Guide to the TDF specification gives an overview and commentary on the TDF language, explaining some of the more difficult concepts.

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.

1.2. What is TenDRA?

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.

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.

1.3. Using the TenDRA Compiler

The main user interface to the TenDRA compiler, tcc, can be used as a direct replacement for the system compiler, cc(1). This is described in the TCC Users' Guide.

There is an alternative user interface, , which just applies the static program checks and disables code generation. Thus corresponds to lint(1) in the same way that tcc corresponds to cc(1).

The chief difference between tcc 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 -Xc option specifies ISO C with no extensions and no extra checks, the -Xa option specifies ISO C with common extensions, and -Xs specifies ISO C with no extensions and lots of extra checks. Similarly -Yc89 specifies the ANSI C89 API (excluding Amendment 1), -Yposix specifies the POSIX 1003.1 API etc. It is also possible to make tcc use the system headers on the host machine by the use of the -Ysystem option. The -Yc++ option is required to enable the C++ facilities. The default mode is equivalent to -Xc -Yc89.

How to configure the C compiler checks is described in more detail in the C/C++ Checker Reference Manual. The extra checks available in C++ are described in the C/C++ Producer Configuration Guide.

1.4. TDF Producers

A tool which compiles a high-level language to TDF, is called a producer. The TenDRA software contains producers for the C and C++ languages. The original TenDRA C producer (tdfc) has now been superseded by a new C producer (tdfc2) based on the C++ producer (tcpplus).

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 TDF and Portability.

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.

The C++ producer implements most of the language sections of the November 1997 draft ISO C++ standard. The known problem areas are:

• Automatic inter-module instantiation of templates is not yet fully implemented.

• The current implementation of exception handling is not optimal with respect to performance.

• Temporaries are not always destroyed in precisely the right place.

• Partially constructed objects are not destroyed properly.

• The visibility of friend functions is not right.

(<new>, <typeinfo> and <exception>) have been implemented. If a complete implementation of the standard C++ library is required, it must be obtained from elsewhere. See the C/C++ Producer Configuration Guide for more details.

1.5. TDF Installers

A tool which compiles TDF to a machine language, is called an installer. TDF installers for a number of Unix systems and processors are included within the release (see the list of supported platforms). Each installer consists of code from three levels:

1. 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.

2. 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.

3. 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.

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 initial_value 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).

1.6. TDF Tools

There are various tools included within the software for viewing, generating and transforming TDF. tspec excepted, the use of these components is integrated into the user interface, tcc, but they may also be called directly.

tspec

The API checking facilities of the TenDRA compiler are implemented by means of abstract interface specifications generated using the tspec tool.

This tool and specifications for a number of common APIs are included with the release. Part of the installation process consists of pre-compiling the implementations of those APIs implemented on the target machine into TDF libraries. This is performed automatically using tcc to combine the tspec specification with the implementation given in the system headers.

tld

tld is the TDF linker. It combines a number of TDF capsules into a single capsule. It also can be used to create and manipulate libraries of TDF capsules.

This functionality is provided by tcc, but tld may be called directly.

disp

disp is the TDF pretty printer. It translates the bitstream comprising a TDF capsule into a human readable form.

This functionality is provided by tcc, but disp may be called directly.

tnc

tnc is the TDF notation compiler. It acts as a sort of TDF “unstructured assembler”, and can translate TDF capsules to and from a human readable form.

This functionality is provided by tcc, but tnc may be called directly.

tpl

tpl is the PL_TDF compiler. It is a TDF “structured assembler” in the lineage of PL360. tpl provides a more user-friendly way of generating TDF capsules from scratch than that offered by tnc.

This functionality is provided by tcc, but tpl may be called directly.

1.7. Compiler Writing Tools

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: