[Vm-dev] Integer overflow with BitBlt rule 20 and depth 32

[Juan Vuletich]

David T. Lewis wrote:
>  
> On Sat, Oct 24, 2009 at 10:40:17AM -0300, Juan Vuletich wrote:
>   
>> What worries me a bit is the other changes I needed to do to be able to 
>> run the Smalltalk BitBlt simulation and to do the translation. These are:
>> BitBltSimulator >> #oopForPointer:   "May be harmless"
>> CArrayAccessor >> #long32At:         "Why is this needed?"
>> CArrayAccessor >> #long32At:put:      "Why is this needed?"
>> CCodeGenerator >> #emitCConstantsOn:  "Consequence of recent changes to 
>> Dictionary >> #keys. Most likely harmless. May be other senders aroud! 
>> (yes, in the very same method there is another sender that would be 
>> optimized by #asSet!"
>>
>> I've not been following the development of VMMaker closely enough to 
>> advise on them, so please everybody, check and comment on them.
>>     
>
> Juan,
>
> I think I finally figured out why the #oopForPointer: and #long32At: and
> #long32At:put: are needed.
>
> I went back to look at Squeak 3.7 and Squeak 3.8 images with VMMaker as
> distributed in those images. The #testAlphaCompositingSimulated and
> #testAlphaCompositing2Simulated tests both pass in those older images.
>
> I then looked at a Squeak 3.8 with the latest VMMaker installed, and
> these two tests fail. The difference is that when the original 64-bit
> VM work was done in 2004, the #oopForPointer and #long32At: and
> #long32At:put: calls were added, but not implemented in BitBltSimulator
> and CArrayAccessor.  This was probably just an oversight, and the problem
> has not been noticed until you spotted it now.
>
> Therefore I think that your added #oopForPointer and #long32At: and
> #long32At:put: methods are correct, and that they do need to be added
> to VMMaker.
>
> Dave

Hi Dave,

Great! Thank you!

Cheers,
Juan Vuletich