[squeak-dev] Is anyone else running a 64-bit image on a regular basis?

David T. Lewis lewis at mail.msen.com
Mon Sep 8 15:49:42 UTC 2014


On Mon, Sep 08, 2014 at 08:35:55AM +0200, Nicolas Cellier wrote:
> 2014-09-07 16:21 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
>
> > On Fri, Jul 18, 2014 at 04:01:45PM -0300, Casimiro de Almeida Barreto
> > wrote:
> > >
> > > On 16-07-2014 00:27, David T. Lewis wrote:
> > > >
> > > > I tend to switch back and forth between a variety of VMs and images
> > (Spur, Cog,
> > > > interpreter VM etc). Lately I have been doing my updates from a
format
> > 68002
> > > > 64-bit image. Just curious, is anybody else out there using a 64-bit
> > image on
> > > > a regular basis and keeping it updated from the trunk development
> > stream?
> > > >
> > >
> > > It works but:
> > >
> > > a) Seems to be slow (although I'm used to the cogvm which is faster
than
> > > SqueakVM)
> > > b) Somethings just itch my ears like:
> > > b.1) Compiler recompileAll fails (and shouldn't)
> > > b.2) Smalltalk condenseChanges that works for 32bit images work, fails
> > > in 64bit image.
> > >
> > > b.2 is not that important but b.1 shows that there is code that cannot
> > > be re-compiled and it's not a good sign.
> > >
> > > (using trunk updated 64bit image and 4.10.2-2614_64bit SqueakVM)
> > >
> >
> > I fixed a small but nasty bug in one of the primitives that appears to
have
> > been the cause of quite a few problems:
> >
> >
> > http://lists.squeakfoundation.org/pipermail/vm-dev/2014-September/016443.html
> >
> > With freshly compiled VM, Compiler recompileAll and Smalltalk
> > condenseChanges
> > are working again in a 64-bit image.
> >
> > Dave
> >
> >
> >
> Ah, the beauty of C signed arithmetic model...
> We should try to avoid it as frequently as we can.
>

Actually, in this case it was not related to signed arithmetic. It was a
word size issue involving a variable that took the default sqInt
declaration (which may be 64 bits) when it should have been explicitly
declared as a 32 bit variable in order to match the logic elsewhere in the
primitive. The shift operation itself was working fine, but the primitive
was trimming the result to 32 bits without failing the primitive.

Arguably the primitive should be updated to use a 64 bit variable so that
larger shift amounts will succeed. But I don't know if this might have
performance implications on various platforms, so I did not make that
change.

Dave







More information about the Squeak-dev mailing list