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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Mar 8 17:45:23 UTC 2022


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220308/4a7fbf8b/attachment.html>


More information about the Vm-dev mailing list