[Vm-dev] [commit][3673] Provide VM hooks for testing Integer class in plugins

[Nicolas Cellier]

2016-04-21 3:33 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:

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

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160421/bc76df2d/attachment-0001.htm