<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Bert,</div><div><br>On Dec 29, 2014, at 4:45 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span></div></blockquote><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">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></blockquote><div class=""><br class=""></div><div class="">Well, up to 53 bits it's OK to convert an integer to a double, it's lossless.<br class=""></div></div></div></div></blockquote></div></div></div></blockquote><br class=""></div>How about making SmallIntegers be 53 bits? Could the VM be as efficient if it masked off more bits? <div class=""><br class=""></div><div class="">IMHO the additional 8 bits we get by going to 61 bits will not significantly enhance performance. In fact, the payoff is probably rather small beyond 32 bits (but still useful e.g. for bit shifts beyond the 32 bit boundary).<br class=""><div class=""><br class=""></div><div class="">The question is why only some operations should fail if the SmallInt has more than 53 bits, or if we should consistently switch to LargeInts above that. OTOH wasting 8 bits in every SmallInt oop may not be a good tradeoff.</div></div></div></blockquote><div><br></div>Doesn't feel right for me. All we're considering is a few floating-point primitives which need an additional failure case. Whereas truncating 64-bit SmallInteger has its own negative effects (microsecond clock range, many more large integers created, eg when dealing with addresses, temptation to find uses for missing bits, such as another ~2^11 tag patterns). Good to mention an alternative but feels wrong to me.<div><br><blockquote type="cite"><div><div class=""><div class=""><br class=""></div><div class="">- Bert -</div></div><div class=""><br class=""></div></div></blockquote></div></body></html>