Hi guys!
I finally pushed the new compiler in master, it is now used by default. This compiler offers several improvements compared to the old one: - Object-oriented - Semantic analysis - Intermediate Representation (flatten, no specific semantic aspects of Smalltalk, etc) that is easy to optimize - Properly tested (although some more tests are needed) - Smarter inlining The new compiler toolchain compiles from source code in 5 steps (the inlining is optional): 1. AST 2. Semantic analysis (AST annotation + validation) 3. IR 4. IR with inlining 5. JS output The semantic analysis gives us interesting informations: - variable scope - variable shadowing - block/method scopes - unknown variables as well as semantic validation. The Intermediate Representation is much simpler and closer to JS compared to the Smalltalk AST, allowing us to perform better inlining: - Inlined blocks (ifTrue: ifNil:, etc) - inlined non local returns - move assignments, returns, etc. when required Inlining examples: The new compiler can perform inlinings like the following (note inlined returns, etc): true ifTrue: [ ^ 1 ] if(smalltalk.assert(true) { return 1; } -- a := b ifTrue: [ 2 ] if(smalltalk.assert(b) { a = 2; } -- ^ b ifFalse: [ self ] if(!smalltalk.assert(b) { return self; } I would like to thank Herby for his work on inlining that I integrated here (the implementation turns out to be different though). -- Nicolas Petton http://nicolas-petton.fr |
Nicolas Petton wrote: > Hi guys! > > I finally pushed the new compiler in master, it is now used by default. > This compiler offers several improvements compared to the old one: > > - Object-oriented > - Semantic analysis > - Intermediate Representation (flatten, no specific semantic aspects of > Smalltalk, etc) that is easy to optimize > - Properly tested (although some more tests are needed) > - Smarter inlining > > The new compiler toolchain compiles from source code in 5 steps (the > inlining is optional): > > 1. AST > 2. Semantic analysis (AST annotation + validation) > 3. IR > 4. IR with inlining > 5. JS output I should get accustomed to it... when I saw #visitInlinedIfTrue: or something like that, I facepalmed and stop to watch it. It just seemed unbearable to me to include visitor for every inlined selector... but I may have misunderstood something. > The semantic analysis gives us interesting informations: > - variable scope > - variable shadowing > - block/method scopes > - unknown variables > > as well as semantic validation. > > The Intermediate Representation is much simpler and closer to JS > compared to the Smalltalk AST, allowing us to perform better inlining: > > - Inlined blocks (ifTrue: ifNil:, etc) > - inlined non local returns > - move assignments, returns, etc. when required > > Inlining examples: > > The new compiler can perform inlinings like the following (note inlined > returns, etc): > > true ifTrue: [ ^ 1 ] > > if(smalltalk.assert(true) { > return 1; > } > > -- > > a := b ifTrue: [ 2 ] > > if(smalltalk.assert(b) { > a = 2; > } I think this misses 'else { a = nil; }' ... > > -- > > ^ b ifFalse: [ self ] > > if(!smalltalk.assert(b) { > return self; > } ... and this misses 'else { return nil; }'. I hope it is just the error written in this mail and the code in fact generates the missing branches. > I would like to thank Herby for his work on inlining that I > integrated here (the implementation turns out to be different though). Thanks. > Herby |
On Wed, 26 Sep 2012 14:41:45 +0200, Herby Vojčík <[hidden email]> wrote: > I should get accustomed to it... when I saw #visitInlinedIfTrue: or > something like that, I facepalmed and stop to watch it. It just seemed > unbearable to me to include visitor for every inlined selector... but I > may have misunderstood something. Well, we can talk about it of course, but isn't this better than manipulating strings around with a stateful & error prone do-it-all compiler? > > ^ b ifFalse: [ self ] > > > > if(!smalltalk.assert(b) { > > return self; > > } > > ... and this misses 'else { return nil; }'. I hope it is just the error > written in this mail and the code in fact generates the missing branches. Well, yes :) This is just pseudo code written to explain the idea, not actual code generated by the compiler. Nico -- Nicolas Petton http://nicolas-petton.fr |
Nicolas Petton wrote: > On Wed, 26 Sep 2012 14:41:45 +0200, Herby Vojčík<[hidden email]> wrote: >> I should get accustomed to it... when I saw #visitInlinedIfTrue: or >> something like that, I facepalmed and stop to watch it. It just seemed >> unbearable to me to include visitor for every inlined selector... but I >> may have misunderstood something. > > Well, we can talk about it of course, but isn't this better than > manipulating strings around with a stateful& error prone do-it-all compiler? Definitely, I just think it went a bit overboard, but I may be wrong, since I did not thoroughly study the solution. > > >>> ^ b ifFalse: [ self ] >>> >>> if(!smalltalk.assert(b) { >>> return self; >>> } >> ... and this misses 'else { return nil; }'. I hope it is just the error >> written in this mail and the code in fact generates the missing branches. > > Well, yes :) This is just pseudo code written to explain the idea, not > actual code generated by the compiler. Ok. Thanks that it is in master already. Is the whole Amber rebuilt (or tried if it works when it is completely rebuilt)? > Nico Herby |
On Wed, 26 Sep 2012 15:21:06 +0200, Herby Vojčík <[hidden email]> wrote: > > > Nicolas Petton wrote: > Is the whole Amber rebuilt (or tried if it works when it is completely > rebuilt)? Yep, it's completely rebuilt. Nico -- Nicolas Petton http://nicolas-petton.fr |
Free forum by Nabble | Edit this page |