[Vm-dev] Re: VM Maker: VMMaker.oscog-tfel.1862.mcz

[Eliot Miranda]

> On May 20, 2016, at 6:37 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> 
>> On 20.05.2016, at 14:03, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 
>> 2016-05-20 13:17 GMT+02:00 timfelgentreff <timfelgentreff at gmail.com>:
>>> 
>>> Sorry, I wasn't careful here and got confused by the method name and comment,
>>> thinking we're talking platform integers here. I updated the method to
>>> truncate to 32-bit.
>> 
>> That's why I like having diffs in mailing lists :)
> 
> Yep :)
> 
>> Note that your new code is correct, and the intention might be clearer than original code.
>> But it removed the SmallInteger optimization if the host image is 32bits…
> 
> … 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).
> 
>> +       (self >= -16r80000000 and: [self <= 16r7FFFFFFF])
>> +               ifTrue: [^self].
>> 
>> above code does imply large integers on those platforms.
>> I didn't measure if it really has an impact on simulation, maybe not, but this should be verified first. 
> 
> Yes, we just checked and it’s definitely slower on 31-bit-int Spur due to its inefficient 32-bit LargeInteger comparisons.
> 
> 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.

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 signedIntFromLong versions and just use my commit as the tip.

> 
> - Bert -
> 
> (*) Having SmallInteger31, SmallInteger32, and SmallInteger63 subclasses of SmallInteger would be crazy, right?

:-). 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 SmallInteger31 and the large integers, but on RSqueak there would be instances of SmallInteger32 and the large integers?

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.

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?

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160520/6eb2ba86/attachment.htm