2014-06-10 14:32 GMT+02:00 GOUBIER Thierry <[email protected]>: > Hi Clement, > > I'm hitting the maximum jump size limit. The method is around 10000 > characters long, with a sequence of ifTrue: ifFalse: >
Hello, For now, this issue is hard to solve. The maximum length of a jump is 1024 instructions (cf bytecode table here: http://clementbera.wordpress.com/2013/09/23/squeakv3plusclosure-bytecode-set/ ). The problem of computing the maximum bytecode length of a sequence form a parse tree is that each AST nodes may generate bytecodes of a variable length. In addition, control flow optimizations are done in Opal after the AST, therefore a block node may generate bytecodes of very different sizes. Lastly, we will change the bytecode set in a few months (partly to solve the issue you have) and your bytecode length assumptions will not be valid any more. I think the best way is to catch the error while compiling and override the error behavior. Right now a generic error is raised but it can be fixed. Look at: IRBytecodeGenerator>>jumpForward: , jumpBackward: , jump:if: Replace all the error signals by something like: self error: 'forward jump too big' ====>>> JumpTooBigCompilationError new info: specificInfosFromCompilerToTipSmaCCOnHowToGenerateWorkingCode; signal. Then you can catch it for your compilations. [ "compilation code" ] on: JumpTooBigCompilationError do: [ :ex | "exception handling code" ]. For example: [ Smalltalk compiler source: 'foo ^ nil'; class: Object; failBlock: [^ nil]; compile ] on: JumpTooBigCompilationError do: [ :ex | SmaCC new regenerateMethodBasedOn: ex info ]. However, this issue will be solved in Pharo 4 in a few months. The maximum number of instructions a jump can handle will be increased from 1024 to around 32000. If this is still not enough for you, tell us then we'll patch the compiler backend and the VM front end to work with more important instruction size. Clement > > Thierry > ------------------------------ > *De :* Pharo-dev [[email protected]] de la part de > Clément Bera [[email protected]] > *Envoyé :* mardi 10 juin 2014 08:15 > *À :* Pharo Development List > *Objet :* Re: [Pharo-dev] Pharo compilation limits > > > > > 2014-06-10 2:23 GMT+02:00 GOUBIER Thierry <[email protected]>: > >> Hi all, >> >> anybody would have a way to determine the maximum length / maximum >> complexity of a method in a Pharo out of a parse tree (or whether if the >> parse tree is over the limit)? >> >> There are many different issues: maximum number of literals, maximum > jump size, maximum number of temporaries. Can you precise what problem do > you have ? What errors are raised ? > > >> The code SmaCC generates easily hit compiler limits (methods too long or >> too complex), and I have difficulties changing the code generation approach. >> > > For Pharo 4, we are implementing a new compiler back end that will > remove some of those limits. I have a problem with code generation too and > we are solving it. > > Clément > >> >> Thanks, >> >> Thierry >> >> >> >
