[Vm-dev] New Cog VMs available
David T. Lewis
lewis at mail.msen.com
Sat Mar 12 05:04:46 UTC 2016
On Fri, Mar 11, 2016 at 05:39:56PM -0800, Eliot Miranda wrote:
> Hi David,
> > On Mar 11, 2016, at 4:36 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >> On Fri, Mar 11, 2016 at 11:05:03AM -0800, Eliot Miranda wrote:
> >> Spur:
> >> Resolve the conflict between 32-bit and 64-bit tag assignments. In 32-bits we
> >> have 1=even SmallIntegers, 2=Characters, 3=odd SmallIntegers, and in 64-bits we
> >> had 1=SmallIntegers, 2=Characters, 3=SmallFloats. Hence we would want
> >> SmallFloat64's identityHash to be 3, which conflicts with 32 bits' odd
> >> SmallIntegers. Change is for 64-bits to use 1=SmallIntegers, 2=Characters,
> >> 4=SmallFloats. This also means single-bit tests in the Cogit, which produces
> >> better code, and no scratch registers to hold masked tags.
> >> Hence roll the 64-bit Spur image format version number from 68019 to 68021.
> >> Delegate to the object memories to determine the image format version
> >> number.
> > Hi Eliot,
> > I wonder if it may be possible to retain the original 69019 image format
> > number? The reason for my question is that I am looking at updating class
> > ImageFormat to document the change, and it gets a bit hacky looking, so
> > if it was possible to stick with 68019 at this point that would be convenient
> > from the point of view of documenting the image formats.
> > I'm not trying to advocate one way or the other, I just want to ask the
> > question in case it is an easy thing to do from your point of view.
> It was my first instinct, thinking that not many people are using 64-bits yet, but off-list Leve ye and I were discussing and I asked what he thought. I decided to follow his advice. In the end it's better. You scheme does work and I really do think this will be the last change to the 63-bit format fir a while. We still have of the order of 1000 unused version numbers so there's no pressing need to avoid rolling.
> If I hadn't changed the version number the symptom would have been infinite recursion, which can be a frustrated belt slow way to find out one has the wrong version. At least this way it's clear.
More information about the Vm-dev