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