Summary and Conclusions


This appendix is a report on a joint project with Microsoft Research whose goal is the implementation of Oberon as a research language on the .NET interoperability platform. We took the opportunity and slightly revised the original Oberon language and its object model. Our two conceptual main achievements are (1) a unified notion of active objects that subsumes (passive) objects and concurrency, and (2) a unified concept of abstraction called definition that subsumes the concepts of base class and interface.

The current version of the Active Oberon for .NET compiler uses a simple and fast, one-pass, recursive-descent strategy. It is reflectively programmed in Active Oberon for .NET and is able to self-compile. It makes use of .NET's System.Reflection API for internalizing imported classes and interfaces but still produces textual MSIL code. Also, in some cases the current compiler relies on explicit hints provided by the programmer, with "forward" declarations being the most prominent example.

We are currently developing a second version of the Active Oberon compiler. It is again based on the recursive-descent parsing strategy, but will generate a more elaborate intermediate data structure that can serve as a basis for the following improvements:

  • Resolve mutual references in the source code without the need for forward declaration

  • Generate native MSIL code via the System.Reflection Emit API

  • Apply the definition mapping rules in their full generality

Also, in the course of a different, local project, we are currently implementing Active Oberon on a custom flyweight system kernel called Aos [7, 8], running natively on Intel SMP and StrongARM systems. In the end, this effort will allow us to compare the efficiency of the two runtimes and fine-tune our implementations .

Some preliminary benchmarks have shown the JIT optimizer to generate about 50% more efficient native Intel code in comparison with our native (nonoptimizing) Oberon compiler.

We have concentrated in this appendix on the object model, because this topic is most intimately related with "programming in the large" and with interoperability, and because it still harbors ample research potential. However, we should not forget that, quantitatively, the translation of executable statements into the stack engine is still the dominant part of the compiler. In this respect, we have little to criticize: The stack engine is well designed and allows our one-pass, recursive-descent algorithm to emit MSIL code naturally. A minor fine point is a missing instruction for swapping the two topmost elements on the stack. Such an instruction would be beneficial for constant expression folding by the compiler.

A more radical and definitely worthwhile thought revolves around a new API for compiler writers based on a parse tree data structure instead of on MSIL code. Not only would such an API factor out the reflection parts from each compiler, but it would also take the burden from compilers of maintaining their own symbol table. As a net effect, language implementation on .NET would be quite easy, and doors could be opened for the implementation of hundreds of small, special-purpose languages.



Programming in the .NET Environment
Programming in the .NET Environment
ISBN: 0201770180
EAN: 2147483647
Year: 2002
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net