2 External representation of the intermediate code
4 The syntax of the intermediate code was given
5 in the previous section.
6 In this section we will make some remarks about
7 the representation of the code in sequential files.
9 We use sequential files in order to avoid
10 the bookkeeping of complex file indices.
11 As a consequence of this decision
12 we can't store all components
13 of the intermediate code
15 If a phase wishes to change some attribute
17 or wants to add or delete entire procedures
18 (inline substitution may do the latter),
19 the procedure table will only be fully updated
20 after the entire EM text has been scanned.
21 Yet, the next phase undoubtedly wants
22 to read the procedure table before it
23 starts working on the EM text.
24 Hence there is an ordering problem, which
25 can be solved easily by putting the
26 procedure table in a separate file.
27 Similarly, the data block table is kept
30 The control flow graphs (CFGs) could be mixed
32 Rather, we have chosen to put them
33 in a separate file too.
34 The control flow graph file should be regarded as a
35 file that imposes some structure on the EM-text file,
36 just as an overhead sheet containing a picture
37 of a Flow Chart may be put on an overhead sheet
38 containing statements.
39 The loop tables are also put in the CFG file.
40 A loop imposes an extra structure on the
41 CFGs and hence on the EM text.
42 So there are four files:
46 the procedure table file
50 the CFG and loop tables file
52 Every table is preceded by its length, in order to
54 The CFG file also contains the number of instructions of
56 indicating which part of the EM text belongs
68 LENGTH -- number of objects
71 LENGTH -- number of procedures
76 {per_proc} ; -- one for every procedure
78 BLENGTH -- number of basic blocks
79 LLENGTH -- number of loops