Towards a flexible Pharo Compiler
0 likes1,629 views
The document discusses problems with the existing Pharo compiler and proposes a new compiler framework called OPAL. The current compiler has issues with reusability, lack of parametrization, and complex mapping between source code and bytecode. OPAL addresses these by using an AST, explicit compiler contexts, and pluggable visitors. It separates the AST from compilation so tools can reuse it. OPAL also allows configuring compiler options and maps source directly to bytecode for debugging. The new framework provides a foundation for features in future Pharo versions and solves key limitations of the old compiler.
![Compiler Options
• Turn off inlining of ifTrue: and friends
MyClass>>foo
<compilerOptions: - optionInlineIf>
^ #myNonBooleanObject
ifTrue: [ 1 ]
ifFalse: [ 0 ]](https://image.slidesharecdn.com/03-compilerpharo-130910082401-phpapp01/85/Towards-a-flexible-Pharo-Compiler-10-320.jpg)
Towards a flexible Pharo Compiler
- 1. Towards a flexible Pharo Compiler Clement Bera and Marcus Denker
- 2. Three Problems • Architecture is not reusable • Compiler can not be parametrized • The mapping between source code and bytecode is overly complex.
- 3. Reusability • AST is special for the Compiler • Tools use own AST (RB) • AST is destroyed when compiling • No reusable backend/parser...
- 4. No Parametrization • No pluggable archicture • Parser, code generator fixed • No infrastructure for compiler options
- 5. Mapping bc2source • For the Debugger, we need to map bytecode to source offsets • With closures, we need to map temp offsets to real temps. Old Compiler: Encoder builds complex table structure
- 6. Solution: OPAL • New compiler framework for Pharo • Default compiler in Pharo3 • Old Compiler will be a loadable package
- 7. Design • RB AST • Visitors • Bytecode level IR Smalltalk source code Refactoring browser abstract syntax tree Intermediate representation Bytecode RBParser ASTTranslator + IRBuilder IRByteCodeGenerator OCSemanticAnnotator
- 8. Reusability • AST is unchanged • Backend independent AST Interpreter Oz/Hazelnut Reflectivity Metalinks Class Builder Smart suggestions Node navigation
- 9. Parametrization • Explicit compiler context • All visitors are pluggable Smalltalk source code Refactoring browser abstract syntax tree Intermediate representation Bytecode Compilation context
- 10. Compiler Options • Turn off inlining of ifTrue: and friends MyClass>>foo <compilerOptions: - optionInlineIf> ^ #myNonBooleanObject ifTrue: [ 1 ] ifFalse: [ 0 ]
- 11. Mapping • Mapping uses AST directly source codeBytecode foo ^ 1 + 2 + 3 76 77 B0 20 B0 7C IRMethod RBMethodNode RBSequenceNode RBReturnNode RBMessageNode 1 RBLiteral ValueNode 1 IRPushLiteral IRSequence RBLiteral ValueNode 1 IRPushLiteral RBLiteral ValueNode 2 IRReturn RBReturnNode IRSend RBMessageNode 1 IRPushLiteral RBLiteral ValueNode 3 RBMessageNode 2 RBLiteral ValueNode 3 IRSend RBMessageNode 2 B0 + 2 1 2 3 + 2 + 3 ^ 1 + 2 + 3 ^ 1 + 2 + 3 foo ^ 1 + 2 + 3 RBLiteral ValueNode 2
- 12. Performance • Visitors and IR do cost a bit of speed • But not much
- 13. Conclusion • Opal solves the problems of the old compiler • Important basis for many features you will see in Pharo3 and Pharo4
- 14. Conclusion • Opal solves the problems of the old compiler • Important basis for many features you will see in Pharo3 and Pharo4 Questions?