<div dir="ltr">Hi David,<div><br></div><div>   one more time with fewer typos.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 18, 2015 at 8:10 PM, David T. Lewis <span dir="ltr">&lt;<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
On Sat, Jul 18, 2015 at 06:09:22PM -0700, Eliot Miranda wrote:<br>
&gt;<br>
&gt; Hi David,<br>
&gt;<br>
</span>&gt; On Sat, Jul 18, 2015 at 3:49 PM, David T. Lewis &lt;<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>&gt; wrote:<br>
<span class="">&gt;<br>
&gt; &gt;<br>
&gt; &gt; On Sat, Jul 18, 2015 at 08:55:27PM +0000, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a> wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Eliot Miranda uploaded a new version of VMMaker to project VM Maker:<br>
&gt; &gt; &gt; <a href="http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1426.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1426.mcz</a><br>
&gt; &gt; &gt;<br>
</span><span class="">&gt; &gt; &gt; ==================== Summary ====================<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Name: VMMaker.oscog-eem.1426<br>
&gt; &gt; &gt; Author: eem<br>
&gt; &gt; &gt; Time: 18 July 2015, 1:54:29.051 pm<br>
&gt; &gt; &gt; UUID: 94ab92ba-c5c4-4953-8566-a4cd9c38df1f<br>
&gt; &gt; &gt; Ancestors: VMMaker.oscog-eem.1425<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Fix at least one set of 64-bit issues caused by Slang.  In particular<br>
&gt; &gt; the integerObjectOf: code resulted in (objectMemory integerObjectOf:<br>
&gt; &gt; MillisecondClockMask) evaluating to the -1 object, instead of the<br>
&gt; &gt; 16r1FFFFFFF object, which was the cause of the initially nresponsive 64-bit<br>
&gt; &gt; image on the real VM (no problem in the simulator).<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I can&#39;t test now to verify, but I wonder if this change is fixing the<br>
&gt; &gt; right problem.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I&#39;m pretty sure it is.  It only bites in a 64-bit implementation with &gt;<br>
&gt; 31-bit integers.  In the &quot;standard&quot; 64-bit image SmallIntegers are still<br>
&gt; only 31-bits so the issue never occurs.  The issue is that the default type<br>
&gt; of an integer constant in C is int.  So if one has to shift any constant<br>
&gt; such that a non-zero bit will occupy bit 31 (0 relative), it must be cast<br>
&gt; to a long type to avoid sign extension.<br>
<br>
</span>I don&#39;t see it. The size of SmallInteger is enforced by the image, not by<br>
the object memory. There is nothing in the &quot;standard&quot; 64-bit image format<br>
that requires small integers to be restricted to the same limits imposed<br>
by a 32-bit object memory.<br></blockquote><div><br></div><div>But they are, right?  And earlier in the Spur 64-bit work you were encouraging me to restrict their range to that of the 32-bit system to avoid bugs (of which the one below is one).</div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The #integerObjectOf: method answers a sqInt, which may be either 32 or<br>
64 bits. This should just work, and I don&#39;t see a need for conditional<br>
logic other than what might be needed to define the size of sqInt in the<br>
first place.<br></blockquote><div><br></div><div>Unfortunately it doesn&#39;t.  See below.</div><div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
&gt;<br>
&gt; Now of course I could generate all Integer constants with the L or UL<br>
&gt; suffix, e.g.<br>
&gt;<br>
&gt; #define MillisecondClockMask 0x1FFFFFFFL<br>
&gt;<br>
&gt; instead of<br>
&gt;<br>
&gt; #define MillisecondClockMask 0x1FFFFFFF<br>
&gt;<br>
&gt; but that&#39;s a much more pervasive change than only generating the cast in<br>
&gt; integerObjectOf when on 64-bits.  So I&#39;m happy with the change that I&#39;ve<br>
&gt; made.  Experience can of course prove me wrong...<br>
<br>
</span>I don&#39;t see the problem. Interpreter class&gt;&gt;initialize does this:<br>
        MillisecondClockMask := 16r1FFFFFFF.<br>
<br>
This works for all combinations or 32 and 64 bit image and host platform.<br>
<br>
There should be no need to generate all of the integer constants with<br>
L or UL suffix. It is perfectly acceptable to assign 16r1FFFFFFF to a<br>
64 bit signed or unsigned variable, and no special handling should be<br>
required.<br>
<br>
I may be missing something, but I do not see anything about the Spur<br>
64-bit image format that should require special handling for this.<br><br></blockquote><div><br></div><span class="" style="border-collapse:collapse;font-size:14px;color:rgb(0,0,0)"><div>Yes, I think you&#39;re missing something.  let me take you through it.  We&#39;re talking about evaluating, in a 64-bit C, sizeof(long) == 8, sizeof(int) == 4, the following two variants:</div><div><br></div><div>#define MillisecondClockMask 0x1FFFFFFF</div><div><br></div><div>(sqInt)((MillisecondClockMask &lt;&lt; 3) + 1L)</div><div><br></div><div>(sqInt)(((sqInt)MillisecondClockMask &lt;&lt; 3) + 1L)<br></div><div><br></div><div><br></div><div>So let&#39;s take the first.  The type of MillisecondClockMask is int.  The type of MillisecondClockMask &lt;&lt; 3 is int.  It&#39;s bit-pattern is 0xFFFFFFF8, and hence its value is, incorrectly, -8.  So it evaluates to the SmallInteger -1, not 16r1FFFFFFF as desired.</div><div><br></div><div>In the second, the type of MillisecondClockMask is int. The type of (sqInt) MillisecondClockMask is long.  The type of ((sqInt)MillisecondClockMask &lt;&lt; 3) is also long, and hence an 8 byte value.  It&#39;s bit pattern is also 0xFFFFFFF8 but its value is 0xFFFFFFF8, /not/ -8, and so it evaluates to the SmallInteger 16r1FFFFFFF as desired.</div><div><br></div></span><div><span class="" style="border-collapse:collapse;font-size:14px;color:rgb(0,0,0)">Does it make sense now?</span> </div></div><br>_,,,^..^,,,_<br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>best, Eliot</div></span></div></div></div>
</div></div>