<div dir="ltr">VM fix (workaround) proposed in VMMakeInbox/VMMaker.oscog-nice.3174</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 10:25, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</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 dir="ltr"><div>IOW, the Character value being unsigned, it would be preferable to use extend A rather than extend B in #genPushCharacter:</div><div>My understanding is that this would require a VM change too...<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 10:08, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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 dir="ltr"><div>Oups forgot to respond to squeak-dev too...<br><br></div><div>in #interpretNextSistaV1InstructionFor: we se that extB is interpreted as signed char</div><div><br></div><div>extB := (extB = 0 and: [extByte > 127])<br> ifTrue: [extByte - 256]<br> ifFalse: [(extB bitShift: 8) + extByte]</div><div><br></div><div>Then in interpretNext2ByteSistaV1Instruction: bytecode for: client extA: extA extB: extB startPC: startPC</div><div><br></div><div>^client pushSpecialConstant: (Character value: (extB bitShift: 8) + byte)</div><div><br></div><div>In our case, extA=0, extB=-128, bytecode=233<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 10:02, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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 dir="ltr"><div>Hi Marcel,</div><div>yes, I agree, the bug is in bytecode encoding/decoding of immediate Character value,</div><div>I stepped into (Compiler evaluate: (String with: $$ with: (Character value: 16r8000))), and if we step into executeMethod, we can inspect what is going on.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 08:39, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">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_-9030679784681934436gmail-m_216817027560204154gmail-m_1890221296999274802gmail-m_398136198968824617__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">
Hi Nicolas --<div></div>
<div><br></div><div>There is a bug in the EncoderForSistaV1. The behavior is okay for EncoderForV3PlusClosures. We can discuss this on squeak-dev now, I suppose.</div><div><br></div><div><span style="font-size:13.3333px">CompiledCode preferredBytecodeSetEncoderClass: EncoderForSistaV1.</span><br></div><div><span style="font-size:10pt">CompiledCode preferredBytecodeSetEncoderClass: EncoderForV3PlusClosures.</span><br></div><div><span style="font-size:10pt"><br></span></div><div><span style="font-size:10pt">If you do send #halt instead of #asInteger, you get another interesting debugger when trying to start debugging:</span></div><div><span style="font-size:10pt"><br></span></div><div><img id="gmail-m_-9030679784681934436gmail-m_216817027560204154gmail-m_1890221296999274802gmail-m_3981361989688246173c61bc55-a92f-4109-bcc8-131cff5f8428" src="cid:17f6de7c489cb971f162" width="318" height="215"><br></div><div><span style="font-size:10pt"><br></span></div><div><span style="font-size:10pt">Best,</span></div><div><span style="font-size:10pt">Marcel</span></div><blockquote 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:rgb(170,170,170);margin-top:10px">Am 09.03.2022 08:34:11 schrieb Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> Ah OK, I see it on macos too
<br>It remains to determine which operation exactly is involved...
<br>The TextMorph holding the printed result is correct - a WideString, whose
<br>last Character is (Character value: 32768).
<br>
<br>Le mer. 9 mars 2022 à 08:08, Marcel Taeumel <u></u> a
<br>écrit :
<br>
<br>>
<br>> Hi Dave, hi Nicolas --
<br>>
<br>> I am working in Windows 10.
<br>>
<br>> > I cannot reproduce on Linux 64 bit either:
<br>> > (Character value: 16r8000) asInteger hex ==> '16r8000'
<br>>
<br>> That's not how you would reproduce it. The bug affects character literals,
<br>> not character objects/instances. You have to evaluate code on that
<br>> character literal.
<br>>
<br>> Maybe this picture helps:
<br>>
<br>>
<br>>
<br>> Best,
<br>> Marcel
<br>>
<br>> Am 08.03.2022 18:56:09 schrieb David T. Lewis <u></u>:
<br>>
<br>> I cannot reproduce on Linux 64 bit either:
<br>>
<br>> (Character value: 16r8000) asInteger hex ==> '16r8000'
<br>>
<br>> Dave
<br>>
<br>>
<br>> On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:
<br>> >
<br>> > Hi Marcel,
<br>> > which OS ?
<br>> > I cannot reproduce on macos 64,
<br>> >
<br>> > Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]
<br>> > 5.20211023.2003
<br>> > Mac OS X built on Mar 6 2022 15:31:16 CET Compiler: 4.2.1 Compatible
<br>> Apple
<br>> > LLVM 10.0.1 (clang-1001.0.46.4)
<br>> > platform sources revision VM: 202110232003
<br>> >
<br>> > Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel a
<br>> > ??crit :
<br>> >
<br>> > >
<br>> > > Hi Eliot, hi all --
<br>> > >
<br>> > > I think we have an sign-bit bug for character literals with code
<br>> points >
<br>> > > 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
<br>> > > #asInteger to it. It will most likely not render in a standard Squeak
<br>> and
<br>> > > 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
<br>> 64-bit,
<br>> > > 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
<br>> 0
<br>> > > in this experiment.)
<br>> > >
<br>> > > VM: 202112201228 (VMMaker.oscog-eem.3116)
<br>> > >
<br>> > > Best,
<br>> > > Marcel
<br>> > >
<br>>
<br>>
<br><div dir="ltr"><div>Ah OK, I see it on macos too<br></div><div>It remains to determine which operation exactly is involved...</div><div>The TextMorph holding the printed result is correct - a WideString, whose last Character is (Character value: 32768).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 9 mars 2022 à 08:08, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">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;min-width:500px"> <div id="gmail-m_-9030679784681934436gmail-m_216817027560204154gmail-m_1890221296999274802gmail-m_398136198968824617gmail-m_-7160874889616242553__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0);text-align:left" dir="ltr">
<br> Hi Dave, hi Nicolas --<div><br></div><div>I am working in Windows 10.</div><div><br></div><div>> <span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">I cannot reproduce on Linux 64 bit either:</span></div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> (Character value: 16r8000) asInteger hex ==> '16r8000'</span><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">That's not how you would reproduce it. The bug affects character literals, not character objects/instances. You have to evaluate code on that character literal.</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 this picture helps:</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><img id="gmail-m_-9030679784681934436gmail-m_216817027560204154gmail-m_1890221296999274802gmail-m_398136198968824617gmail-m_-7160874889616242553377a17ac-9eaa-478e-b331-79d809eb830e" src="cid:17f6de7c488cb971f161" width="343" height="114"><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><br></div><div>Best,</div><div>Marcel</div><div></div>
<br> <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-top:20px;margin-left:0px;padding-left:10px;min-width:500px">
<br> <p style="color:rgb(170,170,170);margin-top:10px">Am 08.03.2022 18:56:09 schrieb David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>>:</p><div style="font-family:Arial,Helvetica,sans-serif"> <br>I cannot reproduce on Linux 64 bit either:<br><br> (Character value: 16r8000) asInteger hex ==> '16r8000' <br><br>Dave<br><br><br>On Tue, Mar 08, 2022 at 06:45:23PM +0100, Nicolas Cellier wrote:<br>> <br>> Hi Marcel,<br>> which OS ?<br>> I cannot reproduce on macos 64,<br>> <br>> Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.3172]<br>> 5.20211023.2003<br>> Mac OS X built on Mar 6 2022 15:31:16 CET Compiler: 4.2.1 Compatible Apple<br>> LLVM 10.0.1 (clang-1001.0.46.4)<br>> platform sources revision VM: 202110232003<br>> <br>> Le mar. 8 mars 2022 ?? 17:57, Marcel Taeumel <u></u> a<br>> ??crit :<br>> <br>> ><br>> > Hi Eliot, hi all --<br>> ><br>> > I think we have an sign-bit bug for character literals with code points ><br>> > 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<br>> > #asInteger to it. It will most likely not render in a standard Squeak and<br>> > 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,<br>> > 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<br>> > in this experiment.)<br>> ><br>> > VM: 202112201228 (VMMaker.oscog-eem.3116)<br>> ><br>> > Best,<br>> > Marcel<br>> ><br><br><u></u></div></blockquote></div></blockquote></div>
<br><u></u><u></u></div></blockquote></div></blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>