| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>Proposed changes</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
|
|
|
8 |
<H1><A NAME=S49>TDF Diagnostic Specification, Issue 3.0</A></H1>
|
|
|
9 |
<H3>January 1998</H3>
|
|
|
10 |
<IMG SRC="../images/no_next.gif" ALT="next section"> <A HREF="diag5.html">
|
|
|
11 |
<IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
12 |
<A HREF="diag1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
13 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
14 |
</A>
|
|
|
15 |
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
|
|
|
16 |
<HR>
|
|
|
17 |
<DL>
|
|
|
18 |
<DT><A HREF="#S50"><B>4.1</B> - Language features currently missing</A><DD>
|
|
|
19 |
<DL>
|
|
|
20 |
<DT><A HREF="#S51"><B>4.1.1</B> - Data types</A><DD>
|
|
|
21 |
<DT><A HREF="#S52"><B>4.1.2</B> - C++ requirements</A><DD>
|
|
|
22 |
<DT><A HREF="#S53"><B>4.1.3</B> - FORTRAN requirements</A><DD>
|
|
|
23 |
<DT><A HREF="#S54"><B>4.1.4</B> - Other requirements</A><DD>
|
|
|
24 |
</DL>
|
|
|
25 |
<DT><A HREF="#S55"><B>4.2</B> - Areas for further abstraction</A><DD>
|
|
|
26 |
<DL>
|
|
|
27 |
<DT><A HREF="#S56"><B>4.2.1</B> - Compilation related</A><DD>
|
|
|
28 |
<DT><A HREF="#S57"><B>4.2.2</B> - C related</A><DD>
|
|
|
29 |
<DT><A HREF="#S58"><B>4.2.3</B> - Naming of types</A><DD>
|
|
|
30 |
</DL>
|
|
|
31 |
<DT><A HREF="#S59"><B>4.3</B> - Postscript: ANDF-DE</A><DD>
|
|
|
32 |
</DL>
|
|
|
33 |
<HR>
|
|
|
34 |
<H1><A NAME=0>4. Proposed changes</A></H1>
|
|
|
35 |
It is thought likely that the new TDF entities described above will
|
|
|
36 |
eventually be incorporated into the main TDF specification.<P>
|
|
|
37 |
In several places below the absence of "standardised methods"
|
|
|
38 |
is noted. These are cases where TDF can express some operation in
|
|
|
39 |
several ways, and the installer cannot be expected to spot all of
|
|
|
40 |
them and generate new diagnostic info.<P>
|
|
|
41 |
|
|
|
42 |
<HR>
|
|
|
43 |
<H2><A NAME=S50>4.1. Language features currently missing</A></H2>
|
|
|
44 |
The following sections list some of the language features known not
|
|
|
45 |
to be supported by the current specification. It is not intended
|
|
|
46 |
to be exhaustive.
|
|
|
47 |
<H3><A NAME=S51>4.1.1. Data types</A></H3>
|
|
|
48 |
<UL>
|
|
|
49 |
<LI>Complex numbers.<P>
|
|
|
50 |
<LI>Fortran alternate <I>RETURN</I>s.<P>
|
|
|
51 |
</UL>
|
|
|
52 |
|
|
|
53 |
<H3><A NAME=S52>4.1.2. C++ requirements</A></H3>
|
|
|
54 |
<UL>
|
|
|
55 |
<LI>The <I>reference</I> type is not yet present.<P>
|
|
|
56 |
<LI>The accessibility attributes (<I>public</I>, <I>private</I> and
|
|
|
57 |
<I>protected</I>) are not yet present.<P>
|
|
|
58 |
<LI>No <I>member</I> function information, and no specification of
|
|
|
59 |
how to deal with name mangling. Pointer to <I>member</I> may need
|
|
|
60 |
special recognition.<P>
|
|
|
61 |
<LI>No operations for describing <I>class</I>es and inheritance.<P>
|
|
|
62 |
</UL>
|
|
|
63 |
|
|
|
64 |
<H3><A NAME=S53>4.1.3. FORTRAN requirements</A></H3>
|
|
|
65 |
<UL>
|
|
|
66 |
<LI>Main <I>PROGRAM</I> attribute missing.<P>
|
|
|
67 |
<LI>Fortran optional parameters may need special treatment<P>
|
|
|
68 |
<LI>Use of <I>COMMON</I> is not explicit in TDF.<P>
|
|
|
69 |
<LI>Fortran77 etc. has a string type, which could be implemented in
|
|
|
70 |
several ways (other languages need this, but they may differ on the
|
|
|
71 |
same machine).<P>
|
|
|
72 |
</UL>
|
|
|
73 |
|
|
|
74 |
<H3><A NAME=S54>4.1.4. Other requirements</A></H3>
|
|
|
75 |
<UL>
|
|
|
76 |
<LI>No standardised method for describing static link info. TDF can
|
|
|
77 |
express such programs, but the link could be stored in several ways.<P>
|
|
|
78 |
<LI>No standardised method for describing arrays with either non-constant
|
|
|
79 |
bounds, and/or where the bounds are present in the running image.
|
|
|
80 |
(The <I>upper_bound</I> and <I>lower_bound</I> <CODE>EXP</CODE>s are
|
|
|
81 |
sufficiently powerful, but needs some rules)<P>
|
|
|
82 |
<LI>No way to name a lexical block.<P>
|
|
|
83 |
<LI>Formal parameters with default values cannot have the default
|
|
|
84 |
made visible.<P>
|
|
|
85 |
<LI>Variables which are constant, and have been inlined everywhere
|
|
|
86 |
may be a problem.<P>
|
|
|
87 |
<LI>No standardised method of describing the discriminant part of
|
|
|
88 |
a discriminated union (in TDF probably represented by a struct containing
|
|
|
89 |
the discriminant and the union).<P>
|
|
|
90 |
<LI>The distinction between ANSI prototyped and non-prototyped functions
|
|
|
91 |
(this is a real problem for functions taking <I>float</I>)<P>
|
|
|
92 |
<LI>No standardised method for PASCAL sets.<P>
|
|
|
93 |
<LI>No standardised method for subrange types.<P>
|
|
|
94 |
<LI>PASCAL and Modula have a <I>WITH</I> construct to change semantics
|
|
|
95 |
of record field lookup. No standardised method for documenting this.<P>
|
|
|
96 |
</UL>
|
|
|
97 |
|
|
|
98 |
<HR>
|
|
|
99 |
<H2><A NAME=S55>4.2. Areas for further abstraction</A></H2>
|
|
|
100 |
|
|
|
101 |
<H3><A NAME=S56>4.2.1. Compilation related</A></H3>
|
|
|
102 |
How a running program has been created from several components is
|
|
|
103 |
of interest when debugging. The present system cannot record all details
|
|
|
104 |
of how a program has been created. In particular there is no indication
|
|
|
105 |
of the source language of any piece of TDF, nor of the full name of
|
|
|
106 |
any of the source files.<P>
|
|
|
107 |
|
|
|
108 |
<H3><A NAME=S57>4.2.2. C related</A></H3>
|
|
|
109 |
At present there is no defined link between the fundamental C types
|
|
|
110 |
and the <CODE>VARIETY</CODE>s etc. used for them. Present installers
|
|
|
111 |
for 32 bit machines cannot distinguish between <I>int</I> and <I>long</I>
|
|
|
112 |
when generating diagnostics, other than by means of the standard token
|
|
|
113 |
names which form part of the C producer language interface.
|
|
|
114 |
<H3><A NAME=S58>4.2.3. Naming of types</A></H3>
|
|
|
115 |
At present various <CODE>DIAG_TYPE</CODE>s have names, some don't.
|
|
|
116 |
I suspect we should make a separate <I>is_named</I> operation and
|
|
|
117 |
remove the other names.<P>
|
|
|
118 |
|
|
|
119 |
<HR>
|
|
|
120 |
<H2><A NAME=S59>4.3. Postscript - ANDF-DE</A></H2>
|
|
|
121 |
As this section makes clear, the TDF Diagnostic Specification was
|
|
|
122 |
only ever really intended to deal with C. As of 1997, a more extensive
|
|
|
123 |
diagnostic extension to TDF, ANDF-DE, is under development by DDC-I.
|
|
|
124 |
This has been designed with the requirements of C, C++ and Ada in
|
|
|
125 |
mind. It is intended that eventually ANDF-DE will be incorporated
|
|
|
126 |
into the TDF specification, and the diagnostic format described here
|
|
|
127 |
will be denegrated.<P>
|
|
|
128 |
|
|
|
129 |
<HR>
|
|
|
130 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
131 |
Copyright © 1998.</I></P>
|
|
|
132 |
</BODY>
|
|
|
133 |
</HTML>
|