Limitation of number os literals in a method?

>
> On Sat, Jul 31, 2010 at 1:57 AM, nullPointer <[hidden email]> wrote:
>
> I get that error when I try save a CLView builded with the UIBuilder
>
> More than 256 literals referenced.
> You must split or otherwise simplify this method.
> The 257th literal is: 128
>
> Select Proceed to continue, or close this window to cancel the operation.
>
>
>
> How I can solve that problem? The method than I try save is generated
> programmatically...
>
> A proper fix requires new bytecodes, but if your method contains lots of explicit literal references, not just lots of message selectors or global varaiables, then there is a workaround.  The problem is due to encoding ranges in message send and literal reference bytecodes which are limited to a 0 to 255 single byte range.  There is no way around this limitation for message selectors or global variables without defining as bytecode with an extended range, but for explicit references if you put your literals in multiple arrays and access them by index you can pool the indices.  This can be done either at the compiler level or at the generation level, but you should start working at the generation level.  e.g.
>
> myMethod
>     | litPool0 litPool1 litPool2 litPool3 |
>     litPool0 := #( a literal array with up to 128 elements).
>     litPool1 := #( a literal array with up to 128 elements).
>     litPool2 := #( a literal array with up to 128 elements).
>     litPool3 := #( a literal array with up to 128 elements).
>     ....
>     self doSomethingWith: (litPool2 at: 127)
>     ...
>
> Your method now uses 1 literal for each pool and 1 literal for each array index other than 1 & 2 (1 & 2 have special bytecodes for them, as does the selector #at:).  So, assuming every index is used, the above method uses 4 + 126 = 130 literals, leaving 126 literals for selectors and globals, while providing access to 512 explicit literals in the pool literal arrays.  If you were to make the literal pools 256 elements large you'd loose because you'd need as many literals for the indices 3 to 256 as you saved from making the literal pool indirect.  So using more smaller pools increases the total number of  literals, e.g. with 8 64-element pools the above example uses 8 + 62 = 70 literals.
>
> When we can get to it we need to redefine the bytecode set to extend these ranges.  Take a look at the VisualWorks bytecodes for a better encoding scheme.
>
> HTH
> Eliot
>  
>
> Thanks
> --
> View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308740.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> I get that error when I try save a CLView builded with the UIBuilder
>
> More than 256 literals referenced.
> You must split or otherwise simplify this method.
> The 257th literal is: 128
>
> Select Proceed to continue, or close this window to cancel the operation.
>
>
>
> How I can solve that problem? The method than I try save is generated
> programmatically...
>
> Thanks
> --
> View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2308740.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> Finnally I call for each widget another method spec for configure it. Is
> possible now reproduce the same error, but is much more difficult.
>
> http://paste.lisp.org/display/113020#1
>
> I wait that version it seems less revolting to Randal  xD
>
> I will upload that fix in SqueakSource UIBuilder project.
>
> Anyway I don´t understant really the problem of limitation at 256 literals.
> Is for VM?

>
> Regards
> --
> View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp2308740p2310239.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> If performance is not a problem , then you could wrap things in one array, like:
>
> array := #(
>
> ( #selector1 arg1 arg2 arg3)
> ( #selector2 arg1 arg2 arg3)
> ( #selector3 arg1 arg2 arg3)
> ( #selector4 arg1 arg2 arg3)
> ...
> )
>
> then in compiled method you'll have only a single literal - and outer
> array, and everything else will sit within it:
>
> array do: [:msg |
>  container perform: msg first withArguments: msg allButFirst ]
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project