researchv10no/cmd/cfront/ooptcfront/README - annotate

Return to README CVS log

Up to [Research Unix] / researchv10no / cmd / cfront / ooptcfront

Annotation of researchv10no/cmd/cfront/ooptcfront/README, revision 1.1.1.1

1.1 root 1:
2: 8 November 1989
3:
4: This file describes the content of the version of cfront prepared at
5: ODI for transmission to AT&T.
6:
7: DESCRIPTION
8:
9: The version of cfront in this directory is a subset of the current
10: development version of cfront at Object Design, Inc. Its primary
11: purpose is to implement parameterized types. However, it includes a
12: few other changes.
13:
14: The precise content of this version is a compromise between two goals.
15: The first goal was to make a compiler with parameterized types
16: containing as little different as possible from 2.00. The second goal
17: was to make a compiler that we were substantially confident introduced
18: no bugs, either in the parameterized type area proper or in the rest
19: of the language.
20:
21: It would be very difficuly to demonstrate that a particular bug fix is
22: not required for the template facility. Therefore, this version
23: includes all of the bugfixes and imnprovements to low-level substrate
24: that were either directly needed by parameterized types or difficult
25: to remove without risk of breaking them.
26:
27: The major changes from 2.0 are listed here. Detailed descriptions of
28: bug fixes are supplied in the file BUGFIXES.
29:
30: CHANGES
31:
32: 1- Substrate and Debugging Support
33:
34: a- tree walking and copying
35:
36: The parameterized type implementation depends on the ability to apply
37: an procedure to each node of a tree resulting from syn() in order to
38: copy it, applying the parameterization. The tree walker supplies this
39: functionality. tree_walk.c and tree_walk.H contain the tree walker.
40:
41: In order to for the tree walker to work, it must be able to determine
42: by examination which fields of any given nodes contains nodes that
43: need to be walked further, and which contain other quantities. In
44: 2.00, several unions punned storage between nodes and other things in
45: ways that were difficult or impossible to disambiguate by examination
46: of the node in question. Therefore, we added some new fields to nodes
47: in order to remove these ambiguities. We also changes some auxiliary
48: structures to be based on node so that the tree walker could process
49: them.
50:
51: The tree walker uses the "discriminator" member functions of the
52: various nodes with unions. These functions take a node and a union
53: index and return an index identifying a particular union member.
54: In fact, this is more information that the walker needs, since once it
55: knows that a field contains a pointer to a subtype of node it can tell
56: what kind of node it is by examining the base.
57:
58: The walker needs to know which base values correspond to which
59: structures. node_classes.H records that information.
60:
61: The tree copyier is an application of the tree walker that copies a
62: syn() tree. It is used directly by the template implementation.
63:
64: b- tree dumping
65:
66: Another application of the tree walker is the tree dumper. It displays
67: the tree symbolically, and can handle dcl processed trees. It is built
68: to be runnable either in cfront or in a debugger. At ODI, our debugger
69: has a command to print cfront nodes that makes use of this.
70:
71: The +OTfile control argument to cfront causes a dump of the syn() tree
72: for each top level item in turn.
73:
74: c- storage management
75:
76: There are three changes to storage management. First, the
77: constructors that assign to this are replaced by new and delete
78: operators. We found this made it much easier to set breakpoints to
79: discover where nodes were deleted inappropriately.
80:
81: Second, no storage is recycled during the compilation of one top level
82: item. Deleted nodes are accumulated on the free list until the end of
83: the current top level item, and then are made available to the next
84: one. This reduces greatly the impact of misplaced uses of delete, and
85: leaves many more tracks of problems that would otherwise be written
86: over by node reuse.
87:
88: Finally, the +OD option forces runtime checking at a few critical
89: places for processing of a node which has already been deleted.
90:
91: 2- Parameterized Types
92:
93: <Sam should insert a description here>
94:
95: 3- limit_renaming
96:
97: <rick can improve this I hope>
98:
99: To make debugging of c++ programs easier, ODI added a mode of
100: operation to cfront that makes the variable names in the generated C
101: code correspond much more closely to the variable names in the c++
102: code.
103:
104: In a modern C compiler (such as Sun's), there is no need for the __N
105: tags on scalar variables or the structure name tags on structure
106: elements. The +Ogx argument to cfront removes these and other
107: unneccessary renamings, making the resulting code much easier to read.
108:
109: 4- constant enforcement
110:
111: This version of cfront enforced const in all cases that we have been
112: able to test. In particular,
113:
114: struct C{
115: int x;
116: };
117:
118: const C c;
119:
120: c.x = 1;
121:
122: is an error as it should be.
123:
124: The implementation strategy is to propagate const up the expr tree
125: from DOT operators as needed.
126:

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.