[Vm-dev] Integer overflow with BitBlt rule 20 and depth 32
David T. Lewis
lewis at mail.msen.com
Thu Oct 29 03:27:58 UTC 2009
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.
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
More information about the Vm-dev