98cpp.gml

来自「开放源码的编译器open watcom 1.6.0版的源代码」· GML 代码 · 共 448 行 · 第 1/2 页

:H3.Project Name: CPP - Watcom C++ Compiler
:cmt. Jan. 1, 1997 - Dec. 31, 1998
:P.
Work was continued to create a C++ compiler.
The objective of this project was to produce a highly optimizing
C++ compiler compatible with our existing C compiler.
The major areas of development included:
:UL.

:LI.
The C++ language syntax is ambiguous.  A statement, of unbounded length, can
be syntactically either a declaration or an executable call to a function.
In such situations, a declaration must be chosen.
This presents a significant implementation problem which competing
implementations have attempted to solve heuristically: all known
implementations fail after a small number of input tokens.
:P
Our new parsing implementation uses a LALR(1) grammar.
Parsing ambiguities are resolved by executing simultaneous parsers
on the same input.
We previously abandoned this approach as unworkable because it was thought
that an exponential number of parallel parsers might be required
for pathological C++ statements.  An exponential number of parsers
would have meant that a large amount of computer resources would be
required for statements with a small number of ambiguities.
Further study revealed that the C++ language was defined in such
a way that we could resolve ambiguities in the language using
a linear number of parsers.  This was a major breakthrough because
a statement with 10 ambiguities that would have required 1024 parsers
can be disambiguated with 20 parsers with our current implementation.
:P
We know of only one (non-competing) other commercial implementation of C++ which
correctly parses the complete C++ language.
The technology developed is a significant asset for Watcom.
:P.
This technology continues to be leading-edge years after its introduction.
The correctness of the C++ compiler parsing has enabled Watcom to
contribute key insights to the C++ standardization effort.
In fact, section 8.2 paragraphs 2 to 6 were copied verbatim from
a paper presented by Watcom.

:LI.
The C++ language definition may cause a function and its data to be
generated from many separately-compiled source modules.
Duplicates need to be discarded when the object files are linked together
to form a program.
This requires the linker to recognize common elements and to appropriately
combine them.
:P
The language specifies all the functions which operate in conjunction
with a C++ class.
A specific program may require only a subset of all the possibilities.
The linker can discard those functions and data elements that are not
required by a specific program.
:P
Existing implementations have been observed to discard simple functions.
No implementation successfully discards virtual functions.
:P
Watcom has devised a method whereby all unreferenced items can be discarded.
This technology requires partial snapshots of the program structure
to be combined by the Watcom linker.  The technical difficulties
included how to represent the information, how to minimize
the information, and how the linker should use the information.
This technology will enable Watcom to produce smaller programs than
competing companies.
:P.
Work continued in the area of improved linking support.
Refinements in the compiler-linker relationship have allowed Watcom C++
to improve the correctness of our C++ implementation along with
improving the linker response time.
:P.
The increased use of Dynamic Load Libraries (DLL) has impacted our
linker level optimization technology.  The use of a DLL forces the
linker to assume that it cannot see the entire program thus reducing
the possibilities for optimization.  Watcom is researching new techniques
that are compatible with the new view of programs using DLLs.
:P.
The linker-level optimizations are not user-friendly when it
comes to using object files that do not have the correct
information in them.  To address this problem, the first steps
of adding a signature to the object file that indicates that
the contents cannot be optimized has been initiated.
This will go a long way to improving the development
process using the Watcom C++ compiler.


:LI.
The C++ language has an elaborate methodology for handling exceptional
conditions called exception handling (EH).
:P
Watcom started the implementation effort with the goal of producing
a fully functional C++ compiler with all of the current features
described in the ISO/ANSI C++ draft.
Watcom has implemented the complete definition of C++ exceptions.
:P.
This year we introduced a higher speed and more advanced implementation
of C++ exception handling based on our early experience.  We are currently
maintaining our lead in the marketplace with our exception handling
technology.
:P.
Based on our experience with the new method of exception handling, we
developed techniques within the compiler so that the compiler is simpler
to maintain and enhance.  The end result is object code that is similar
to our faster implementation but much easier to maintain and verify correctness.

:LI.
A larger view of optimization is required for high performance C++ compilers.
The research into optimizing C++ code is still in its infancy so a lot
of the optimizations included in the Watcom C++ compiler are completely new.
:P.
Advanced analysis of simple constructors and destructors is
applied to optimization.  The Watcom C++ compiler analyzes complete
structures in order to optimize the generation of compiler generated
routines.  The introduction of some new code level optimizations designed
for C++ in the code generator has also solidified our position as the
best optimizing compiler.
:P.
New optimizations take advantage of functions which do not
throw exceptions.  These techniques reduce
or eliminate the need for compiler generated "bookkeeping" code that
contributes to the bloat of current C++ generated code.  

:LI.
The C++ language is complicated enough that we had to develop and refine
our testing procedures for the Watcom C++ compiler.  The compiler is
tested during every step of its development to ensure that it performs
correctly in all cases.  This is an iterative process because we continue
to learn and discover new facets of the C++ language.  The testing
has helped us to produce a stable and correct compiler early in the
development cycle.  This has been an on going process throughout the
development of the compiler.
:P.
This year has seen a large growth in our regression test suite.  A
regression test suite forms a repository for reported problems with
the compiler along with a self checking test case (if possible).
This technology helps to prevent the reintroduction of problems
into the compiler that can happen easily due to the complexity
of the compiler.
:P.
The regression test suite has been expanded and is now being used
everyday to verify the correctness of the current shipping version
of the C++ compiler.  This was done before major releases in previous
years but we have found that running the regression test stream
everyday helps to keep problems in the compiler to a minimum.
The expanded use of C++ at Watcom is also an important component
of our testing of the C++ compiler.
:P.
The regression test suite continues to be a strategic
tool for the Watcom C++ compiler.  It's influence is spreading
to many of the other tools within the Watcom C++ product.
This year saw the adoption of the C++ test harness by
one to two projects within Watcom.  The Java group adopted the
testing system from the start of the project.
:P
The test suite is also used by other groups to validate their work
as they make changes to components used by the C++ compiler.


:LI.
Compiling the C++ language can be time consuming for a developer since
the compilers are often processing the same code over and over again
even though it is known that there are no errors.  A method for not
duplicating the analysis of already working code moved up in priority
with the quantum leap in operating system complexity this year.
The header files for the new operating systems are richer and more
complicated than ever before so speeding up the processing of these
files of source code became an important task.
:P
The method we used to solve this problem is called a pre-compiled header file.
The problems encountered in implementing this feature of the compiler include
saving and restoring the complete internal state of the compiler.  This 
involved research into the latest papers on persistent objects combined
with some Watcom innovations.  The completed implementation satisfied our
goal of increased throughput during compilation of C++ source code.

:LI.
A commercial compiler needs to perform efficiently, in terms of both time and 
space, on any size of input. An algorithm that accomplishes this by
dynamically adapting to the current requirements (called dynamic hashing)
was adopted this year for the hash table, a key component of the compiler.  
:P.
Dynamic hashing varies the number of bits of the hashed key that are 
used when determining which bucket will hold the given key.  As the buckets 
become more full (causing longer average linear searches when looking up keys 
in the hash table), another bit of the hashed key is used.  This increases 
the number of buckets used, decreasing the average linear search time.  The
particular dynamic hashing algorithm implemented ("Dynamic Hash Tables",
Per-Ake Larson, CACM April 1988 Vol.31, Num.4) splits one bucket at a time as
the desired average search length is exceeded, instead of doubling the size of
the entire hash table when this limit is exceeded.  The result is fine-grain 
control over performance, allowing performance to scale smoothly with 
problem size (number of unique keys to be store).

:LI.
The adoption of the C++ compiler as an interactive tool continues to drive
the primary development effort.
The first problem that had to be solved was to develop
techniques to "restart" the compiler so that the compiler
executable did not have to be reloaded before compiling
another source file.  This is accomplished in modern operating
systems by creating a C++ compiler Dynamic Loadable Library (DLL).
:P.
The C++ compiler uses a large shared code base so the "restart"
problem has to pushed into all of the code that the C++ compiler
uses in a client manner.  Some of the code is obsolete and so
it could not be changed easily, for these cases, the C++ compiler
had to adapt to the obsolete code's requirements.
:P.
Interactive environments demand high speed compilation.
There are two possibilities for increasing the speed
of a compilation, namely, make the compiler do less
work and feed less data into the compiler.
:P.
Improvements to the loading of
pre-compiled header files increased the
compilation speed.  The reduction of data was aided
by instrumenting the compiler internally to produce
reports on what was happening in the compiler.
This allowed us to modify our input into the compiler
so that repeated compiles were faster than our fastest
competitor.


:LI.