0
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

266

Published on

Clement Bera and Marcus Denker

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
266
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "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?
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×