Annotation of researchv10no/cmd/cfront/ooptcfront/README, revision 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.