<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On May 20, 2016, at 6:37 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=utf-8">On 20.05.2016, at 14:03, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" class="">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">2016-05-20 13:17 GMT+02:00 timfelgentreff <span dir="ltr" class=""><<a href="mailto:timfelgentreff@gmail.com" target="_blank" class="">timfelgentreff@gmail.com</a>></span>:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
Sorry, I wasn't careful here and got confused by the method name and comment,<br class="">
thinking we're talking platform integers here. I updated the method to<br class="">
truncate to 32-bit.<br class=""></blockquote><div class=""><br class=""></div><div class="">That's why I like having diffs in mailing lists :)<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>Yep :)</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Note that your new code is correct, and the intention might be clearer than original code.<br class="">But it removed the SmallInteger optimization if the host image is 32bits…</div></div></div></div></div></blockquote><div><br class=""></div><div>… only if the VM uses 31 bit ints ;) The whole point was to speed up RSqueak which uses true 32 bit SmallInts, and executes the simulation code all the time (instead of compiling it into VM primitives).</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">+ (self >= -16r80000000 and: [self <= 16r7FFFFFFF])<br class="">
+ ifTrue: [^self].<br class=""><br class=""></div><div class="">above code does imply large integers on those platforms.<br class=""></div><div class="">I didn't measure if it really has an impact on simulation, maybe not, but this should be verified first. </div></div></div></div></div></blockquote><br class=""></div><div>Yes, we just checked and it’s definitely slower on 31-bit-int Spur due to its inefficient 32-bit LargeInteger comparisons.</div><div><br class=""></div><div>I don’t see a good way to make this work optimally on VMs with 31 bit, 32 bit, and 63 bit SmallInts at the same time (*) … So the best is probably to just revert to the lowest common range check, which is for 31 bits.</div></div></blockquote><div><br></div>Right, which is why, when I committed my recent changes I ignored the two commits. Now what we have, with the latest commit is a commit comment that refers to the signedIntFromLong method but the changes include all those from my commit. I think it best to simply discard the <span style="background-color: rgba(255, 255, 255, 0);">signedIntFromLong versions and just use my commit as the tip.</span><div><br><blockquote type="cite"><div><br class=""><div class="">
- Bert -<br class=""><br class=""></div><div class="">(*) Having SmallInteger31, SmallInteger32, and SmallInteger63 subclasses of SmallInteger would be crazy, right?</div></div></blockquote><br></div><div>:-). So you mean make SmallInteger an abstract class and have concrete immediate subclasses for the different widths so that on Cog & Interpreter VMs there would be instances of <span style="background-color: rgba(255, 255, 255, 0);">SmallInteger31 and the large integers, but on RSqueak there would be instances of SmallInteger32 and the large integers?</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Yes, I think that's crazy because it's throwing image compatibility out of the window, and in the simulator implies a x 3 fan out in the number of object memory classes.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">But you know that I think RSqueak is crazy too as it implies effort put into RSqueak is effort that is not being put into Sista, and that makes me feel very sad and confused by the fact that people don't want to help Cog get better. Is it an issue of belief, that those working in RSqueak don't believe the Sista architecture can work?</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I'm unhappy that the RSqueak folks are introducing changes in the VMMaker.oscog branch that occasionally break it, but they're apparently uninterested in improving Cog. Bert forked to make JSqueak work. If one is changing VMMaker.oscog one should be doing so for the benefit of Cog, not to sabotage it.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">There, I've said my piece. I hope no one takes this personally. I don't mean any of it as a personal attack. I very much like and respect all the people I've met working in RSqueak, Tim, Patrick, Tobias et al. But the affection and respect doesn't change the fact that I feel that Cog is underesourced and is being used as a means to an end by those that would rather see a non-Smalltalk VM technology thrive than put effort into helping a Smalltalk VM technology improve. It seems like very slowly but very deliberately shooting oneself in the foot.</span></div></body></html>