Monolithic Compiler


Your new C++ development environment must integrate and build on an existing compiler (say, gcc). However, the existiing compiler is designed to be run as an independent process. It produces either binary or textual output files.

The new environment should be extensible: you want to let third paries add new tools to it. These tools should have access to the "compiler output": this means everything from cross reference information through to assembly code.

How would you design the interaction between the existing compiler, the development environment, and any extensions.

Who contributed this problem? Please sign it with a link back to a personal page.


This is a very good point. I also think that the compiler currently is a black-box: the interface between the compiler and the IDE is text based, and the AST is internal to the compiler.

Instead, I think that the compiler should expose a clean and well-defined API surface - an OO facade, which would allow to: 1. pass text to the compiler to parse it and to receive an AST node as a result 2. pass the AST or part of it to the compiler for different purposes (resolving types, producing byte-code, etc.)

The AST should be in one central place and the compiler should be watching it, updating it, keeping it intact, and in general, being responsible for the AST. In particular, the front-end should be more involved in IntelliSense and other features - it should provide services for all AST consumers.

The back-end should be clearly-separated from the front-end into a separate module. It should be pluggable, i.e. the tools should be able to intercept the code-generation process at any stage and to get access to the data structures at each step (useful for meta-programming, code generation, AOP, etc).

I write more about this in my thesis: http://www.osenkov.com/diplom/contents/1/3

Kirill Osenkov, http://www.osenkov.com

 

Last edited June 16, 2007
Return to WelcomeVisitors