Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Towards a flexible Pharo Compiler Clement Bera and Marcus Denker
Three Problems • Architecture is not reusable • Compiler can not be parametrized • The mapping between source code and byt...
Reusability • AST is special for the Compiler • Tools use own AST (RB) • AST is destroyed when compiling • No reusable bac...
No Parametrization • No pluggable archicture • Parser, code generator fixed • No infrastructure for compiler options
Mapping bc2source • For the Debugger, we need to map bytecode to source offsets • With closures, we need to map temp offse...
Solution: OPAL • New compiler framework for Pharo • Default compiler in Pharo3 • Old Compiler will be a loadable package
Design • RB AST • Visitors • Bytecode level IR Smalltalk source code Refactoring browser abstract syntax tree Intermediate...
Reusability • AST is unchanged • Backend independent AST Interpreter Oz/Hazelnut Reflectivity Metalinks Class Builder Smart...
Parametrization • Explicit compiler context • All visitors are pluggable Smalltalk source code Refactoring browser abstrac...
Compiler Options • Turn off inlining of ifTrue: and friends MyClass>>foo <compilerOptions: - optionInlineIf> ^ #myNonBoole...
Mapping • Mapping uses AST directly source codeBytecode foo ^ 1 + 2 + 3 76 77 B0 20 B0 7C IRMethod RBMethodNode RBSequence...
Performance • Visitors and IR do cost a bit of speed • But not much
Conclusion • Opal solves the problems of the old compiler • Important basis for many features you will see in Pharo3 and P...
Conclusion • Opal solves the problems of the old compiler • Important basis for many features you will see in Pharo3 and P...
Upcoming SlideShare
Loading in …5
×

Towards a flexible Pharo Compiler

1,395 views

Published on

ESUG IWST 2013

Published in: Technology
License: CC Attribution License
no profile picture user

  • Be the first to comment

  • Be the first to like this

Towards a flexible Pharo Compiler

  1. 1. Towards a flexible Pharo Compiler Clement Bera and Marcus Denker
  2. 2. Three Problems • Architecture is not reusable • Compiler can not be parametrized • The mapping between source code and bytecode is overly complex.
  3. 3. Reusability • AST is special for the Compiler • Tools use own AST (RB) • AST is destroyed when compiling • No reusable backend/parser...
  4. 4. No Parametrization • No pluggable archicture • Parser, code generator fixed • No infrastructure for compiler options
  5. 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. 6. Solution: OPAL • New compiler framework for Pharo • Default compiler in Pharo3 • Old Compiler will be a loadable package
  7. 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. 8. Reusability • AST is unchanged • Backend independent AST Interpreter Oz/Hazelnut Reflectivity Metalinks Class Builder Smart suggestions Node navigation
  9. 9. Parametrization • Explicit compiler context • All visitors are pluggable Smalltalk source code Refactoring browser abstract syntax tree Intermediate representation Bytecode Compilation context
  10. 10. Compiler Options • Turn off inlining of ifTrue: and friends MyClass>>foo <compilerOptions: - optionInlineIf> ^ #myNonBooleanObject ifTrue: [ 1 ] ifFalse: [ 0 ]
  11. 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. 12. Performance • Visitors and IR do cost a bit of speed • But not much
  13. 13. Conclusion • Opal solves the problems of the old compiler • Important basis for many features you will see in Pharo3 and Pharo4
  14. 14. Conclusion • Opal solves the problems of the old compiler • Important basis for many features you will see in Pharo3 and Pharo4 Questions?

×