[Vm-dev] Sign-bit bug in character literals > 16r7FFF ... related to SistaV1?

[David T. Lewis]

I cannot reproduce on Linux 64 bit either:

  (Character value: 16r8000) asInteger hex ==> '16r8000' 

Dave


On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:
>  
> Hi Marcel,
> which OS ?
> I cannot reproduce on macos 64,
> 
> Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]
> 5.20211023.2003
> Mac OS X built on Mar  6 2022 15:31:16 CET Compiler: 4.2.1 Compatible Apple
> LLVM 10.0.1 (clang-1001.0.46.4)
> platform sources revision VM: 202110232003
> 
> Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel <marcel.taeumel at hpi.de> a
> ??crit :
> 
> >
> > Hi Eliot, hi all --
> >
> > I think we have an sign-bit bug for character literals with code points >
> > 16r7FFF.
> >
> > Steps to reproduce:
> >
> > 1. Print it: "Character value: 16r8000"
> > 2. Inspect the result by evaluating the character literal or send
> > #asInteger to it. It will most likely not render in a standard Squeak and
> > show up like "$? asInteger".
> >
> > In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.
> > In a 64-bit VM, I will get the (negative) integer value '-16r8000'.
> >
> > Somehow, starting at bit 0, the bits 16 to 29 flip from 0 to 1. In 64-bit,
> > this means a negative number. Not sure about bits 30 and 31 here.
> >
> > Is there a bug in the upper tag bits of immediate characters?
> > Is this related to the 2-byte or 3-byte byte codes in SistaV1?
> >
> > Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine was 0
> > in this experiment.)
> >
> > VM: 202112201228 (VMMaker.oscog-eem.3116)
> >
> > Best,
> > Marcel
> >