doc/reflection.txt

   1 Lestes compiler
   2
   3 The C++ compiler conforms the ISO/IEC 14882:2003(E) standard except for the
   4 lack of support for exported templates. This new feature of the standard
   5 was not yet implemented by any other compiler vendor.
   6
   7 Lestes is able to compile any C program which is a C++ program at the same
   8 time. Support for differences between C and C++ was not implemented due to
   9 lack of time.
  10
  11 Support for all the key parts of the C++ language is full-value.
  12
  13
  14 - namespaces
  15     implemented
  16
  17 - multiple inheritance
  18     implemented
  19
  20 - overloaded functions, user defined conversions
  21     implemented
  22
  23 - virtual funcions
  24     implemented
  25
  26 - inlined functions
  27     work but not inlined
  28     (as permited by the ISO standard)
  29
  30 - templates
  31     implemented
  32     (maybe up to details. as partial specialization partial ordering)
  33
  34
  35 -----------------
  36
  37 Lestes framework
  38
  39 - Using standard compiler constructing tools
  40     Yes. It was found however that use of such standard tools hinders maintainability
  41     and extensibility. These tools are not suitable to deal with the peculiarities
  42     of the C++ language. Both flex and bison were manhandled to fit our needs
  43     at the expense of diminishing maintainability and extensibility.
  44
  45 - Systematic implementation of semantic analysis (by means of attribute grammars)
  46     This goal was achieved only partially. Many provisions of the standard averted
  47     us from more thorough application of attribute grammars to the semantic analysis.
  48     some parts of the standard were formulated in an explicitely imperative manner,
  49     which was not deemed worthy to rework in declarative way.
  50
  51 - Rigorous use of standard containers from STL and protective techniques of C++
  52     While it was decided to use garbage collector to lift burden of memory management
  53     from the ordinary programmer it was impossible to use STL containers directly.
  54     Adapters were developed to bridge the incompatibilities between garbage collected
  55     objects and standard containers.
  56
  57     In the course of developing garbage collector, the techniques of "smart pointers"
  58     were extensively used, again not to burden the programmer with the use of garbage
  59     collection.
  60
  61 - Modern intercode representation (DAG)
  62     Several modern intercodes Whirl (Open64), SSA, DAG) were explored and used as
  63     a model for our own intercode. At first it was desided to use a sort of SSA
  64     intermediate representation, which combines the power of DAG with ease
  65     of implementing future optimizations. This approach was abandoned due to the lack
  66     of time. The DAG-likeness was retained nevertheless.
  67
  68 - Strict separation and modularity of key blocks of the compiler
  69     The separation of extensive use of namespaces and the modularity with strict objective
  70     design. The low stages of intercode are designed with source language independece in mind
  71     as well as the target machine independence. The upper layers of the intercode are not
  72     possibly language-neutral as they reflect the source code more closely.
  73
  74     During the course of developement a helper component was made that allows to specify object
  75     classes in a language independent manner. However only sample implementation generating
  76     C++ code was implemented.
  77
  78 - Modular realization of all optional phases (optimizations)
  79     While there were provided no optimization phases and the code generator is just a simplistic
  80     proof-of-concept one it is concievable that such modules would be inserted into the code
  81     generator, perhaps replacing part of it.
  82
  83 - Independence of the data stuctures and algorithms on the target platform
  84     Achieved completely.
  85
  86
  87 We have decided to follow the Itanium C++ ABI draft specification, which is used by GCC since
  88 version 3.2 even on the IA32 platform. This decision makes the code interoperable with compilers
  89 on GNU/Linux and Windows operating systems.
  90
  91 The completeness of the analytical part was achieved.
  92
  93 For future educational purposes, the feature of dumping data structures is noteworthy.
  94 Lestes offers a transparent dump of data structures at any chosen moment during runtime.
  95 The output format is XML, so it can be relatively easily transformed into any other format.
  96 (For example into DIA by XSLT.) Transformations of the source code representation can be
  97 visualised this way.
  98