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

[David T. Lewis]

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