[Vm-dev] 64 bits (was: Squeak Oversight Board minutes ? 5/01/12)

[David T. Lewis]

On Fri, May 04, 2012 at 11:59:10AM +0200, Bert Freudenberg wrote:
> 
> 
> On 04.05.2012, at 10:16, Casey Ransberger wrote:
> 
> > Below.
> > 
> > On May 4, 2012, at 12:55 AM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> > 
> > (huge snip, context is in the rest of the thread)
> > 
> >> IMHO, that's not only a question of handling huge image, there might
> >> be an advantage for some applications with more speed-efficient object
> >> format like for example:
> >> 
> >> 1) immediate double values (like VW SmallDouble)
> >> 2) immediate characters
> >> 3) 32 bit integers, signed or unsigned - that would simplify a lot of
> >> handlings, and greatly accelerate LargeInteger arithmetic which is
> >> still based on 8bit operations on our 64 bits machines !
> >> 
> >> Nicolas
> > 
> > Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a couple of reasons to design in particular directions as a way to illustrate that the road to 64-bit is not well defined for us yet, I did so to point out that just bitwidth isn't the only important consideration, and he's pointed out that even the arguments I presented as examples *grossly* underthink the issues involved. 
> > 
> > To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think it's something to strive for, but there are some wonderful people using this VM with different goals, and perhaps unfortunately, learning what we all need from a 64-bit VM is likely to be a longish conversation. 
> > 
> > In any event, though, #doIt! Make it work, if you want it, and then the rest of the world will be quite out of your way while you're using what you've made. At least in Squeak, we can do stuff like that. 
> > 
> > CC Eliot because it's his baby and I don't even know what I'm talking about:) At least, he can probably speak to the challenges around 64-bit support as well as absolutely anyone else around.
> > 
> > 
> > Casey
> 
> 
> IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box.
> 
> - Bert -
>

I agree. Aside from the work of building and distributing these VMs, the
two most serious issues to be addressed are these:

http://bugs.squeak.org/view.php?id=7237
0007237: Make FFI work on 64 bit platforms

http://bugs.squeak.org/view.php?id=7433
0007433: Gstreamer and Pango plugins fail on 64-bit host

Both of these involve pointer-to-int issues affecting the image(s),
the Slang, and the support code on multiple platforms.

A set of fixes was available for the FFI issue a few years ago (but
not pushed through due to some other higher priorities). This could
presumably be updated and applied to the various FFIs now in circulation,
but it will take some work and coordiation of multiple branches and
platforms to pull it off.

No fix is available for the Gstreamer/Pango issue, but I regard this
as equally high priority because the underlying issue is in the
SurfacePlugin, and fixes are likely to involve updates to images,
VMMaker(s), and platform code.

Aside from these, I think that any remaining 64-bit issues are
likely to be easily dealt with, at least in the sense that the
fixes will be limited in scope and can be done without a lot
of image/vm/plugin/support code coordination.

I should say though that we are actually in much better shape
than might be implied by the above. I use a 64-bit VM pretty much
all the time on my desktop (Cog too of course) and I have no
problems (I don't use FFI or Pango). And a 64-bit VM is perfectly
suitable for server deployments. There is no problem at all for
someone who is aware of the limitations and willing to compile
their own VM. But distributing a 64-bit VM to lots of people
who expect it to "just work" is another matter, I don't think
we're there just yet.

Dave