Towards a flexible Pharo Compiler
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Towards a flexible Pharo Compiler

on

  • 853 views

ESUG IWST 2013

ESUG IWST 2013

Statistics

Views

Total Views
853
Views on SlideShare
852
Embed Views
1

Actions

Likes
0
Downloads
3
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Towards a flexible Pharo Compiler Presentation Transcript

  • 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?