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

[Juan Vuletich]

Hi Folks,

David T. Lewis wrote:
> It should be OK to add the type declarations only where they are actually
> needed for comparison and multiply.
>
> Just FYI it is worth noting that the default sqInt is an 64 bit long
> when generating code for a 64 bit image VM, so it is generally good
> practice to explicitly declare the int and unsigned types when doing
> 32 bit arithmetic. Unfortunately this looks like it would be a huge
> amount of tedious work for the bitblt plugin, so I would not worry
> about it for now (but it would be good to make some unit tests for
> these problems so it will be possible to validate the fixes on a 64
> bit image later).
>
> I'll try building a VM this weekend if nobody else has gotten to it by
> then. Note, I have zero expertise with bitblt (but I may still be able
> to help with the debugging).
>
> Dave
>   

Thanks for the offer Dave. I found a little more time last evening and 
this morning. I built a new VM on Windows with the patch I sent 
yesterday. The behavior is now correct, both on my scripts and on 
Henrik's. Using Henrik's script to measure performance, I see a 2% loss 
in rgbAdd, most likely because of the comparison I added. We could 
unroll the loop and do the new comparison only for the most significant 
partition (i.e. alpha). That would enhance the performance a little bit.

I will do a couple of tests to check that this correct behavior is 
maintained, including in 64bit images and VMs.

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.

Cheers,
Juan Vuletich