eliot

in VW did windows spec faced such a limit and relied on such bytecodes?
I imagine that this is the case but...

Stef

On Jul 31, 2010, at 6:10 PM, Eliot Miranda wrote:

> 
> On Sat, Jul 31, 2010 at 1:57 AM, nullPointer <[email protected]> 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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to