96cpp.gml

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

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.
:P.
The advent of new RISC architectures has required some changes to our
pre-compiled header file implementation.  These changes have been made
to the C++ compiler but have not been tested on true RISC architectures
yet.
:P.
The RISC targeted C++ compiler is now in final stages of testing
and the pre-compiled header technology has in fact changed to adapt
to the new environment.


:LI.
The adoption of the C++ compiler as an interactive tool has been
the primary development effort for this year.
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.
Extensive overhaul of the compiler internals produced
a speed gain of roughly 15-20%.  Improvement of the
pre-compiled header file load posted dramatic gains
in compile 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.
The compilation of class and function templates is still
an ad hoc process.  The internals of the compiler seem
to be robust enough to handle most templates but because
the ISO C++ WP is still not very precise, it is difficult
to decide when to overhaul the compiler handling of templates.
:P.
This year saw the incremental improvement of the template
handling of the compiler.  We hope to add some of the new
features in the ISO C++ WP in the near future.


:LI.
A common theme in the development of the C++ compiler has been
the balance between conforming to the ISO C++ WP and maintaining
compatibility with legacy source code.  The competitive pressure
to adopt subtle changes that allow the Watcom C++ compiler to
compile our competitor's source code is also present.
We have taken the path of issuing warnings in preference to
hard errors for violations that can still generate acceptable
code.  This allows us to diagnose problems in source code
for users that are concerned about minimizing problems but
still support compilation of legacy source code without any
hard errors.
:P.
Another problem with conformance to the ISO C++ WP is that
the standard is still highly volatile and subject to change.
We have taken the stand that we won't implement anything
unless it has survived for roughly a year without change.
Even this conservative manner has resulted in our having
to change the compiler because of a substantial change in
the ISO C++ WP.  We continue to attend the standards
committee meeting in the hope that we can minimize these
kinds of surprises.
:P.
As the WP chapter on overloading has remained mostly unchanged for at 
least a year, our support for overloading has undergone major revisions 
in order to conform more closely to the WP.  To thoroughly 
understand the WP chapter on overloading, several other areas of the WP 
needed to be revisited and re-interpreted in light of their use in the 
context of overloading.  The result was not only the change of overloading 
code, but also the rewrite of type conversion code in order to avoid 
duplication of logic and inconsistent interpretation of the standard 
within the compiler.
:P.
In several cases, it was impossible to conform to both the WP and the
existing practices of our major competitors.  This created the need for the 
compiler to work either way depending on how it is invoked.  In such 
situations, reverse engineering is required in order to understand how the 
competitor must have interpreted the WP.  Once this is established,
a consistent implementation can be created.  
:eUL.

:H5.Run-time libraries

:P.
The Watcom C++ run-time libraries were all developed by Watcom.
Watcom has implemented compiler support routines,
as well as String, Complex and iostreams class libraries.
The industry has only settled on de facto standards for behaviour
in the area of the iostreams class library.
The current ISO C++ standard does not fully define the behaviour
required of the runtime library.
:P.
The tug between existing code and the new ISO C++ Working Paper
continues.  This often requires delicate changes to the various
C++ run-time libraries to maintain an acceptable balance between
these opposing forces.


:H6.The compiler support routines

:P.
The ISO C++ standard was changed to specify that the life-time of 
temporary objects is the duration of a statement. The WATCOM compiler
was implemented with life-times being the duration of a scope.
:P
To support this new definition,
the Watcom C++ compiler exception handling mechanism was restructured.
This required a complete rewrite of most the compiler support routines
because the destruction of objects and exception-handling are an integrated
feature of the language.
:P
The new implementation allows both inline destruction and table-driven (using
run-time routines) destruction of objects.  This increased flexibility permits
a user to generate code optimized for space or time in various ways.
:P.
The use of Operating System specific exception handling mechanisms has
been used in the C++ compiler run-time.  This enables high-speed registration
of exception handling "book keeping" data structures for multi-threaded
applications.  Watcom is exploring the use of more OS-specific exception
handling mechanisms.


:H6.The iostreams class library

:P.
To ensure compatibility with the largest
number of users of the iostreams class library, competitive products,
the draft specification and published works were consulted.
The Watcom iostreams class library was evaluated in terms of conformance
to the de facto industry standard.
:P.
In the process of researching and evaluating the Watcom iostreams
class library conformance an extensive set of test programs were created.
These programs were then bundled into an automated test stream
to ensure continued conformance in the face of future demands on the library.
The construction of the automated test stream environment was complicated
by the multi-platform nature of the Watcom tools.
Each test program is run under all platforms that are supported and must
always produce identical results.  Building the infrastructure required
to support this form of automated test execution and output collection
and verification required further development.
:P.
Additional work was done to ensure that the iostreams class library
performance was in keeping with the Watcom standard for excellence.
This involved creating benchmark programs and then running these
with competitive products.  Deficiencies were found in the Watcom support.
The class library was then modified to address these deficiencies.