<div dir="ltr"><div>Hi Marcel,</div><div>which OS ?</div><div>I cannot reproduce on macos 64,</div><div><br></div><div>Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172] 5.20211023.2003<br>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)<br>platform sources revision VM: 202110232003 </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 8 mars 2022 à 17:57, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div id="gmail-m_-4158331727044520283__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">Hi Eliot, hi all --<div></div><div><br></div><div>I think we have an sign-bit bug for character literals with code points > 16r7FFF.</div><div><br></div><div>Steps to reproduce:</div><div><br></div><div>1. Print it: "Character value: 16r8000"</div><div>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".</div><div><br></div><div>In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.</div><div>In a 64-bit VM, I will get the (negative) integer value '-16r8000'.</div><div><br></div><div>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.</div><div><br></div><div>Is there a bug in the upper tag bits of immediate characters?</div><div>Is this related to the 2-byte or 3-byte byte codes in SistaV1?</div><div><br></div><div>Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine was 0 in this experiment.)</div><div><br></div><div>VM: 202112201228 (VMMaker.oscog-eem.3116)</div><div><br></div><div>Best,</div><div>Marcel</div></div></blockquote></div>