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 improved compiler extensibility.

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?