-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsprut-2.html
323 lines (291 loc) · 12.5 KB
/
sprut-2.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.66">
<TITLE>SPRUT (internal representation description translator): Internal representation description language</TITLE>
<LINK HREF="sprut-3.html" REL=next>
<LINK HREF="sprut-1.html" REL=previous>
<LINK HREF="sprut.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="sprut-3.html">Next</A>
<A HREF="sprut-1.html">Previous</A>
<A HREF="sprut.html#toc2">Contents</A>
<HR>
<H2><A NAME="s2">2.</A> <A HREF="sprut.html#toc2">Internal representation description language</A></H2>
<P>IRD declares types of nodes of the graph. Nodes contains fields, part
of them represents links between nodes, and another part of them
stores attributes of arbitrary types. To make easy describing
internal representation the IRD supports explicitly single inheritance
in node types and also can model multiple inheritance. There can be
several levels of internal representation description in separate
files. The nodes of one level refer to the nodes of previous levels.
Therefore each next level enriches source program internal
representation.</P>
<H2><A NAME="ss2.1">2.1</A> <A HREF="sprut.html#toc2.1">Layout of internal representation description</A>
</H2>
<P>To describe internal representation a special language is used. An
internal representation description structure has the following layout
which is similar to one of YACC file.
<BLOCKQUOTE><CODE>
<PRE>
DECLARATIONS
%%
TYPES OF NODES
%%
ADDITIONAL C/C++ CODE
</PRE>
</CODE></BLOCKQUOTE>
The `%%' serves to separate the sections of description. All sections
are optional. The first `%%' starts section of description of types
of internal representation nodes and is obligatory even if the section
is empty, the second `%%' may be absent if section of additional C/C++
code is absent too.</P>
<P>The section of declarations may contain names of predefined types of
fields of internal representation nodes and names of types of double
linked nodes. The section also contains name of original internal
representation description if given file contains extension of an
internal representation description. And finally the section may
contains sections of code on C/C++.</P>
<P>The next section contains description of types of internal
representation nodes.</P>
<P>The additional C/C++ code can contain any C/C++ code you want to use.
Often functions which are not generated by the translator but are
needed to work with internal representation go here. This code
without changes is placed at the end of file generated by the
translator.</P>
<H2><A NAME="ss2.2">2.2</A> <A HREF="sprut.html#toc2.2">Declarations</A>
</H2>
<P>The section of declarations may contain the following construction.
<BLOCKQUOTE><CODE>
<PRE>
%type IDENTIFIER ...
</PRE>
</CODE></BLOCKQUOTE>
All predefined types must be defined in constructions of such kind.
The same name can be defined repeatedly. All references to node whose
type is a sub-type of type with name present in the following
construction will be double linked.
<BLOCKQUOTE><CODE>
<PRE>
%double IDENTIFIER ...
</PRE>
</CODE></BLOCKQUOTE>
It means that SPI will generates functions (macros) which permit to
examine all fields (may be in other nodes) described as of given node
type (or its subtype) which refer to node of given type (or its
sub-type), i.e. fields which are described as of given node type (or
its subtype) will be double linked (see below). SPI will
automatically maintain such double links. The simplest way to
describe double linked graph is to insert construction
<BLOCKQUOTE><CODE>
<PRE>
%double %root
</PRE>
</CODE></BLOCKQUOTE>
Last construction in the section of declarations of kind
<BLOCKQUOTE><CODE>
<PRE>
%extend IDENTIFIER
</PRE>
</CODE></BLOCKQUOTE>
defines name (without suffix) of file containing source internal
representation which is extended by given file. The file contains
original internal representation if there is no one such construction.
The original specification file has level 0, the extensions have level
1, 2, and so on. This feature permits sequentially to develop an
internal representation and to save and restore any its level (see
SPI) to additional tools, e.g. browsers. For example, there may be
three levels of source program internal representation. The zero
level representation may be internal representation for semantic
analysis, the first level may be a low level machine-dependent
internal representation, and the second level may be used to generate
object code. Only first such construction in one file is essential.
All subsequent such constructions are ignored.</P>
<P>There may be also the following constructions in the declaration
section
<BLOCKQUOTE><CODE>
<PRE>
%local {
C/C++ DECLARATIONS
}
%import {
C/C++ DECLARATION
}
and
%export {
C/C++ DECLARATION
}
</PRE>
</CODE></BLOCKQUOTE>
which contain any C/C++ declarations (types, variables, macros, and so
on) used in the description sections.</P>
<P>The local C/C++ declarations are inserted at the begin of generated
implementation file (see SPI description) but after include-directive
of interface file.</P>
<P>C/C++ declarations which start with `%import' are inserted at the
begin of generated interface file. For example, such C/C++ code may
contain C/C++ definitions of predefined types which are used in field
declarations of node types.</P>
<P>C/C++ declarations which start with `%export' are inserted at the end
of generated interface file. For example, such C/C++ code may contain
definitions of external variables and functions which refer to node
type representation (see type `IR_node_t' in SPI description).</P>
<P>All C/C++ declarations can redefine all type specific and internal
macros (see SPI) because they are placed in implementation file. All
C/C++ declarations are placed in the same order as in the section of
declarations. C/C++ declarations from IRD file with smaller level
number (see construction `%extend') are placed in interface or
implementation files firstly.</P>
<H2><A NAME="ss2.3">2.3</A> <A HREF="sprut.html#toc2.3">Types of nodes</A>
</H2>
<P>The section of declarations is followed by section defining internal
representation node types. An internal node type is described by the
following construction
<BLOCKQUOTE><CODE>
<PRE>
%abstract
IDENTIFIER :: IDENTIFIER (or %root)
CLASS FIELDS
SKELETON FIELDS
OTHER FIELDS
</PRE>
</CODE></BLOCKQUOTE>
Keywords `%abstract' is optional. Node type description which starts
with this keyword denotes abstract node type, i.e. node of such type
does not exist in internal representation of any source program.
Abstract nodes types serve only to description of common fields of
several node types.</P>
<P>The first identifier defines name of internal representation node
type, the second defines name of node type all declarations of fields
of which are inherited into the given node type. In this construction
the first node type is so called immediate super type, the second is
immediate sub-type.</P>
<P>Node type A is a super-type of node type B (and node type B is a
sub-type of node type A) iff node type A is immediate super-type of
super-type of node type B. All node types are sub-types of implicitly
declared node type with name `%root'. There are also nodes of special
type (error nodes). Type of these nodes are believed to be sub-type
of all declared node types. The definition of type of error nodes are
absent in any internal representation description.</P>
<P>The identifier of immediate super-type (with `::') can be absent. In
this case the construction is continuation of given type node
declaration. There can be only the single main node type declaration
and many its continuations. The order of main node type declaration
and its continuations can be arbitrary. The continuations can not
start with keyword `%abstract'.</P>
<P>Construction of the following kind
<BLOCKQUOTE><CODE>
<PRE>
A, B, ... :: C
DECLARATIONS OF FIELDS
</PRE>
</CODE></BLOCKQUOTE>
is abbreviation of the following constructions
<BLOCKQUOTE><CODE>
<PRE>
A :: C
DECLARATIONS OF FIELDS
B :: C
DECLARATIONS OF FIELDS
...
</PRE>
</CODE></BLOCKQUOTE>
The fields are sub-divided on kinds. There are three kinds of fields.
<OL>
<LI>Class fields. There is the single instance of a class field
for all nodes of given type.
</LI>
<LI>Skeleton fields. There is the single instance of a skeleton
fields for each node of given type. The value of skeleton
field is to be given by user at the node creation moment (see
SPI description).
</LI>
<LI>Other fields. This kind of fields is analogous to one of
skeleton fields but value of such field is not given by user
at the node creation moment.</LI>
</OL>
Optional sections of declarations of class fields, skeleton fields,
and other fields start correspondingly with keywords `%class',
`%skeleton', and `%other'.
<BLOCKQUOTE><CODE>
<PRE>
%class LIST OF DECLARATIONS OF FIELDS
%skeleton LIST OF DECLARATIONS OF FIELDS
%other LIST OF DECLARATIONS OF FIELDS
</PRE>
</CODE></BLOCKQUOTE>
These keywords are followed by may be empty list of declarations of
fields. The list elements are field declaration or target code.
Field declaration is described by the following construction:
<BLOCKQUOTE><CODE>
<PRE>
IDENTIFIER : FIELD %double TYPE CONSTRAINTS ACTIONS
</PRE>
</CODE></BLOCKQUOTE>
Identifier is name of given field. All declarations of fields of a
node type must have unique names. But declarations of fields of
different node types can have the same names if the types of such
fields are the same, the fields are simultaneously described as double
linked or not, and all such fields are class or any non-class fields.
Owing to the feature it is possible to model multiple inheritance.
Semicolon `:' is followed by the field type. There are the following
types of nodes fields:
<OL>
<LI>identifier from a clause `%type'. The identifier represents
predefined type and must be declared anywhere by the
construction `typedef' of C/C++.
</LI>
<LI>node name. This type represents arc to a node of given type
or its subtypes and is implemented by pointer of C/C++.</LI>
</OL>
These constructions can have optional clause `%double'. Its sense is
slightly different from the one in the declarations section. This
clause means that SPI will generate functions (macros) which permits
to examine all nodes of the declared type (or its sub-type) which
refer through given field to a node of the field type (or its
sub-type). The clause `%double' can not be given for class fields.</P>
<P>The field type may be followed by constraints and actions in any
order. The constraint is usually present for non-null value node
reference. The constraint is a boolean expression on C/C++ in
brackets `[' and `]'. The constraints are tested with the aid of some
generated functions in the same order as they are present in
corresponding type node declaration. The actions can contain any
statements on C/C++ in figure brackets `{' and `}' (the brackets are
also output therefore C/C++ declarations can be in actions). The
actions for skeleton and other fields are fulfilled at the node
creation time in the same order as they are present in corresponding
type node declaration. The actions for class fields are fulfilled at
the internal representation initiation time.</P>
<P>Constructions `$$', `$' in the constraints and the actions represent
correspondingly current node and previous field. But `$' is not
changed by the previous field if the previous field in given node type
declaration is of other kind than the constraint or action (e.g. the
field of skeleton kind and the constraint of class kind) or such field
does not exist in the current node type declaration. Also it should
be remembered that `$' can not be used in left hand side of assignment
if the construction represent double linked fields.</P>
<P>The construction `IDENTIFIER : FIELD TYPE' may be absent. This case
is convenient for definition of additional constraints and actions for
fields which declared in a super-type of given node type.</P>
<P>Construction of kind
<BLOCKQUOTE><CODE>
<PRE>
A, B, ... : C ...
</PRE>
</CODE></BLOCKQUOTE>
is abbreviation of the following constructions
<BLOCKQUOTE><CODE>
<PRE>
A : C ...
B : C ...
</PRE>
</CODE></BLOCKQUOTE>
Full YACC syntax of internal representation description language is
placed in Appendix 1.</P>
<HR>
<A HREF="sprut-3.html">Next</A>
<A HREF="sprut-1.html">Previous</A>
<A HREF="sprut.html#toc2">Contents</A>
</BODY>
</HTML>