<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-04-21 3:33 GMT+02:00 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.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"><span class=""><br>
On Thu, Apr 21, 2016 at 01:19:18AM +0200, Nicolas Cellier wrote:<br>
><br>
> 2016-04-20 23:50 GMT+02:00 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
><br>
> ><br>
> > Hi Nicolas, Hi All,<br>
> ><br>
> ><br>
> > Nicolas, I'm going to have to roll this form of the change back. The<br>
> > change ignores the versioning convention for the VirtualMachine struct in<br>
> > sqVirtualMachine.[ch]. If you look at the code you see things like:<br>
> ><br>
<br>
</span><snip><br>
<span class=""><br>
> Hi Eliot,<br>
> OK, I see it now, obviously once compiled the names are gone, only the<br>
> position counts...<br>
> No use to break the old feature of providing binary compatibility indeed.<br>
><br>
<br>
</span>Hi Nicolas,<br>
<br>
I'm not certain, but I suspect that some of the class type checking for<br>
primitives in LargeIntegersPlugin may not really be needed at all. We need<br>
to check for SmallInteger (ObjectMemory>>isIntegerObject:), and anything<br>
else whould be a LargePositiveInteger or SmallPositiveInteger, both of<br>
which are variable byte objects (ObjectsMemory>>isBytes:).<br>
<br>
Checking for ObjectMemory>>isBytes: and ObjectMemory>>byteSize: is<br>
probably sufficient for the type checks on parameters, and we also have<br>
ObjectMemory>>classLargePositiveInteger and ObjectMemory>>classSmallPositiveInteger<br>
which can be used for explicit class checks.<br>
<br>
I think that the underlying problem is that SmartSyntaxInterpreterPlugin<br>
was designed to make it easy for end users to write plugins (*) without<br>
needing to worry about type declarations and stack organization. It<br>
achieves this ease of use at the expense of performance, because it<br>
adds type checks that ensure that the code will work, but not necessarily<br>
that it will be fast.<br>
<br>
In the case of LargeIntegersPlugin, it would have been better to<br>
have subclassed directly from InterpreterPlugin, rather than from<br>
SmartSyntaxInterpreterPlugin. Anyone (such as yourself) who is working<br>
on these primitives needs to know what they are doing with low level<br>
implementation details, so the "help" that is provided by the smart<br>
syntax is probably causing more problems than it is solving.<br>
<br>
I am not sure how much work would be needed to reimplement LargeIntegersPlugin<br>
as a subclass of InterpreterPlugin, but I suspect that some of the<br>
primitives would be significantly faster if this could be done.<br>
<br>
Dave<br>
<br>
(*) I still think this is a very worthwhile objective, and I think<br>
we should make it easier for ordinary users to write plugins and<br>
primitives. If you care about reliability and maintainability, it's<br>
hard to beat a plugin. But for some reason, people think it is hard<br>
to do. It should not be hard to do, it should be easy.<br>
<br>
</blockquote></div>Hi David,<br></div><div class="gmail_extra">changing LargeIntegersPlugin hierarchy was my first thought indeed, and my first commit was taking this direction.<br></div><div class="gmail_extra">But as Eliot would say, we can have our cake and eat it too.<br></div><div class="gmail_extra">And type checking is still necessary, we have operands, and we need more than isBytes (sign discussion).<br>Sure, most of type protection is already present at image side, but I always prefer foolproof VM if it's not exagerately expensive.<br><br></div><div class="gmail_extra">Nicolas<br></div></div>