Hi Milan,

on Sun, 25 Feb 2007 00:03:22 +0100, you wrote:
> Hi Klaus,
> On 2007 February 24 04:07, Klaus D. Witzel wrote:
>> Hi Milan,
>>
>> on Sat, 24 Feb 2007 09:53:50 +0100, you wrote:
> <<snip>>
>> >
>> > There are limits in the CompileMethod code such as:
>> > 	nTemps > 63 ifTrue:
>> > 		[^ self error: 'Cannot compile -- too many temporary variables'].
>> > 	nLits > 255 ifTrue:
>> > 		[^ self error: 'Cannot compile -- too many literals variables'].
>> > A naive question, does this have to do with the way classes are
>> > represented in
>> > the VM?
>>
>> Since I am [in part] responsible for having the above checks in a
>> consistent way, here's my part of the answer:
>>
>> No. These limits exist because the header field in CompiledMethod has  
>> room
>> for just these respective number of bits.
>>
>> Has nothing to do with, how classes are represented in the VM, but with,
>> how CompiledMethods are represented in the VM.
>
> Thanks for explaining it. Considering my zero level awareness of how  
> image
> interacts with the VM, and that I never looked at VM code, I should take  
> this
> to the newbies list .. but anyway. I assume this limit only applies to
> methods compiled dynamically using ClassDescription>>compile:classified:  
> and
> friends, not to methods code that I type in browser, is that correct?

No :) There is but one CompiledMethod class so the way you compile doesn't  
matter.

> Also, I
> wonder how other VMs handle this, is it a performance reason that Squeak
> (apparently) allocates fixed space to CompileMethod header (instead of  
> maybe
> making it a linked list)?

You can see the four parts of CompiledMethod better than I can describe  
them here, in a debugger inspect the thisContext item in the bottom right  
pane (second from right); in that inspector inspect the CompiledMethod.  
For example ('abc' at: 0) will start you the debugger, select the line  
which says UndefinedObject>>DoIt.

The part you refer to is the literals array which is directly indexed by  
bit quantities in the bytecode; there's no time for chasing a slow linked  
list ;-)

/Klaus

> Milan
>>
>> >   -# So I ended up "manually serializing" the ByteArray, esentially  
>> as a
>> > literal String such as '80 75 3 4 20 0 0 0 0 0 76 134 203' in the  
>> small
>> > example above. Then deserialized after the method answered.
>>
>> Correct. This way you have only one literal in the CompiledMethod,  
>> instead
>> of one literals for each value less than -1 or greater than 2 :)
>>
>> /Klaus
>
>