<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-12-26 23:07 GMT+01:00 John McIntosh <span dir="ltr"><<a href="mailto:johnmci@smalltalkconsulting.com" target="_blank">johnmci@smalltalkconsulting.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><div dir="auto"><div>I question would be how long would it take to crowd source a Sunit that covers the entire range of 2^64? When we worked on the 32bit clean image I ended up doing the 2^32 range for small integers and large integers after discovering at issue at 2^24 </div><div><br></div></div></blockquote><div> </div><div>It depends, if testing the 2^32 combinations took you 1hour, you might get around the 2^64 in less than 500,000 years...<br></div><div>Unless of course you can parallelize on the 1,5 billion active PC in the world (can a good virus do that?)<br><br></div><div>If you deal with 2^32 tests in 1 second, then less than 150 years will be enough with a single machine (I advise you to wait a few more years before launching the test, that might be the best strategy...)<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br>Sent from my iPhone</div><div><br>On Dec 26, 2014, at 1:58 PM, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-12-26 22:46 GMT+01:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2014-12-26 19:44 GMT+01:00 Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</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><div dir="ltr">Hi Nicolas,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Dec 26, 2014 at 7:48 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><div><div><div>One of the problem I foresee is this one:<br><br> 1.0e17 >= 100000000000000001<br><br></div>indeed, the (generated) primitive currently convert the SmallInteger to double, and this one is true:<br><br> 1.0e17 >= 100000000000000001 asFloat<br><br></div>In 32 bit Spur/COG with 30 bit max magnitude, it was OK because every conversion SmallInteger -> Double was exact - like all integer in the range [-2^53,2^53] - see Float class>>maxExactInteger<br><br></div>In 64 bits Spur, this might not be the case anymore since some SmallInteger exceed this range...<br></div></div></blockquote><div><br></div></span><div>Thanks for the head's up. You're quite right:</div><div><br></div><div>(1 << 60 - 1) asFloat asInteger = (1 << 60 - 1) false</div><span><div><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>So the (generated) primitive must be protected with some range test.</div></div></blockquote><div><br></div></span><div>So in cases where we do double CMP integer or integer CMP double the primitive must fail if the SmallInteger has more than 52 bits of significance? </div></div></div></div></blockquote><div><br></div><div>Well, up to 53 bits it's OK to convert an integer to a double, it's lossless.<br><br></div><div> <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 class="gmail_extra"><div class="gmail_quote"><div> That's reasonable. I need to review the StackInterpreter code to make sure it does the same. I'm pretty sure it doesn't do so right now.</div></div></div></div></blockquote><div><br></div><div>#primitiveLessThan does only compare integers, but #bytecodePrimLessThan tries to be smarter and invoke #primitiveFloatLess:thanArg: then #loadFloatOrIntFrom:<br> <br></div></div></div></div></blockquote><div><br></div><div>So defining a specialized loadFloatOrInt53From: for float/integer compare primitive/bytecode may do the job...<br><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 class="gmail_extra"><div class="gmail_quote"><div></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 class="gmail_extra"><div><br></div><span><font color="#888888">-- <br><div>best,<div>Eliot</div></div>
</font></span></div></div><span><font color="#888888">
<br></font></span></blockquote></div><br></div></div>
</blockquote></div><br></div></div>
</div></blockquote></div>
<br></blockquote></div><br></div></div>