<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">(moved from vm-dev)</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Apr 18, 2017 at 10:27 AM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-04-18 4:02 GMT+02:00 Andres Valloud <span dir="ltr"><<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.<wbr>comcastbiz.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 4/17/17 16:45 , Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
FYI, hash multiply is<br>
hashMultiply<br>
| low |<br>
low := self bitAnd: 16383.<br>
^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low)<br>
bitAnd: 16383) * 16384))<br>
bitAnd: 16r0FFFFFFF<br>
</blockquote>
<br>
[...] that convoluted arithmetic is done this way in Smalltalk only to simulate a 32x32 multiplication bit-anded down to 28 bits without overflowing into large integers (the original code from August 2000 had my initials).<br>
<br>
At a sufficiently low level such as C, all that complexity is just an unsigned multiplication by 1664525. The image code should still have a comment to that effect, did it get lost?<span class="gmail-m_-3854379891857696730gmail-HOEnZb"><font color="#888888"><br>
<br>
Andres.<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">More: if it's a 64 bit image, then we have 60 bit long unsigned small int<br>since 1664525 highBit = 21, and self is a hash result not exceeding 30 bits, we can implement hashMultiply as<br> ^self * 1664525 bitAnd: 16r0FFFFFFF<br></div></div></blockquote><div><br></div><div>Yes I wondered about that too. How could we get different behavior in the 32 vs 64 bit image, while running the same code?</div><div><br></div><div>One way would be to make SmallInteger abstract and have concrete SmallInteger32 and SmallInteger64 subclasses. In a 32 bit image you would only get SmallInteger32 instances, and in a 64 bit image only SmallInteger64 instances. Most methods would remain in SmallInteger, but 32 or 64 bit specific behavior could be implemented in the subclasses. Seems very clean, but sounds like overkill.</div><div><br></div><div>A more hackish but less intrusive way would be to have a Monticello package with *overrides which would only be loaded in 64 bit images. Then again, we try to avoid overrides, and we want to use the same config map in both 32 and 64 bit images.</div><div><br></div><div>Or how about a little compiler hack? Basically the code could read</div><div><br></div><div><div>hashMultiply</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Smalltalk is64Bits</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ifTrue: [^self * 1664525 bitAnd: 16r0FFFFFFF]</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>ifFalse: [</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>| low |</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>low := self bitAnd: 16383.</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>^(16r260D * low + ((16r260D * (self bitShift: -14) + (16r0065 * low) bitAnd: 16383) * 16384))</div><div><span class="gmail-Apple-tab-span" style="white-space:pre"> </span>bitAnd: 16r0FFFFFFF]</div></div><div><br></div><div>and the compiler could recognize that "Smalltalk is64Bits" is constant and generate only one of the branches ... I actually quite like this idea, I think :)</div><div><br></div><div>- Bert - </div></div></div></div>