<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Dave --<div class="mb_sig"></div>
<div><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> The issue will not be related to the upper tag bits of immediate</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> characters, and it will not be related to the 2-byte or 3-byte byte</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> codes in SistaV1. It's just some sort of type declaration issue in</span><br style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> the VM code, that's all.</span><br></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Well, it seems to be a bug in EncoderForSistaV1, as it does not occur in EncoderForV3PlusClosures. :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">And it may be an </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">issue related to integer data types in Windows versus unix-based systems.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Maybe there are two different bugs here? =)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 09.03.2022 00:39:51 schrieb David T. Lewis <lewis@mail.msen.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">On Tue, Mar 08, 2022 at 05:57:32PM +0100, Marcel Taeumel wrote:<br>> Hi Eliot, hi all --<br>> <br>> I think we have an sign-bit bug for character literals with code points > 16r7FFF.<br>> <br>> Steps to reproduce:<br>> <br>> 1. Print it: "Character value: 16r8000"<br>> 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".<br>> <br>> In a 32-bit VM, I will get the (positive) integer value 16r3FFF8000.<br>> In a 64-bit VM, I will get the (negative) integer value '-16r8000'.<br>> <br>> 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.<br>> <br>> Is there a bug in the upper tag bits of immediate characters?<br>> Is this related to the 2-byte or 3-byte byte codes in SistaV1?<br>> <br>> Works fine up to 16r7FFF. (This is unrelated to #leadingChar. Mine was 0 in this experiment.)<br>> <br>> VM:??202112201228 (VMMaker.oscog-eem.3116)<br>> <br>> Best,<br>> Marcel<br>> <br><br>Hi Marcel,<br><br>This integer type declaration stuff is enough to give anybody a headache,<br>so here is a tip to make it slightly less obscure without leaving the<br>comfort of the Squeak image.<br><br>First load package TwosComplement, either from SqueakMap or from<br>http://www.squeaksource.com/TwosComplement.<br><br>Then take a look at the two suspicious integer values that you get from<br>your 32-bit VM and 64-bit VM, rendering them as 32-bit twos complement<br>(the common case for C int on most platforms):<br><br> { 16r3FFF8000 asRegister: 32 . -16r8000 asRegister: 32} inspect.<br><br>or the simpler version (since 32 bits is the default):<br><br> { 16r3FFF8000 asRegister . -16r8000 asRegister} inspect.<br><br>This shows the low order 16 bits (the actual character value) as valid<br>in both cases, and the high order 16 bits as garbage related to integer<br>type declaration and/or sign extension in the VM. <br><br>Very likely this will turn out to be an issue in primitive 171,<br>InterpreterPrimitives>>primitiveImmediateAsInteger. And it may be an<br>issue related to integer data types in Windows versus unix-based systems.<br><br>The issue will not be related to the upper tag bits of immediate<br>characters, and it will not be related to the 2-byte or 3-byte byte<br>codes in SistaV1. It's just some sort of type declaration issue in<br>the VM code, that's all.<br><br>Dave<br><br><br></div></blockquote></div>