[Vm-dev] Potential problems with 64bit spur large SmallInteger comparison

[David T. Lewis]

On Thu, Jan 01, 2015 at 12:59:03PM -0800, Eliot Miranda wrote:
> 
> > My remaining concern would be that handling the logic in the VM (floating point
> > primitives) is less flexible than handling it in the image. I am not really
> > convinced that the immediate float format in Spur 64 will prove to be of
> > practical value, so I think that maintaining some flexibility around the
> > implmentation might be a good thing.
> >
> 
> Based on the experience with 64-bit VisualWorks I can assure you it has an
> impact.  Floating point arithmetic will be considerably faster (2 to 3x)
> and allocations will go way down.

D'oh! I see it now. I was completely overlooking the impact of allocating those
objects. I'm sure you are right.

> 
> So my $0.02:
> >
> > Do it in careful steps. Release 1 of Spur 64 could have immediate short
> > integers
> > in the same range as the 32-bit image. Release 2 could follow Bert's
> > guidance.
> > Release 3 could fix up the various float primitives and extend the range
> > to 61 bits.
> >
> 
> I'm not going to go this way.  I'm going to stick with 61-bit SmallIntegers
> and SmallFloat64s.  We have a comprehensive test suite and this is core
> behaviour.  t's very easy to find issues in this area so, given that the
> code has been written and is working, there's no case for backing out.
> There's really nothing to be gained by being conservative here.  Nicolas'
> concern has been addressed and tests can be written to check.  We can have
> our cake and eat it to.
> 
> Happy New Year!

Happy New Year indeed!

It has been quite remarkable to see the proceeding development of Cog,
Spur and Sista. All the more so in that the work is being done openly,
implemented in Smalltalk, and with an open and public exchange of ideas.
I think that you are leading some remarkable work here, and 2015 promises
to be another very interesting year.

Thanks,
Dave