[Vm-dev] mantis http://bugs.squeak.org/view.php?id=7349

Eliot Miranda eliot.miranda at gmail.com
Thu May 7 16:53:35 UTC 2009


On Thu, May 7, 2009 at 9:36 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> 2009/5/7 Eliot Miranda <eliot.miranda at gmail.com>:
> >
> >
> >
> > On Thu, May 7, 2009 at 8:44 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >>
> >>
> >> On 07.05.2009, at 17:38, Andreas Raab wrote:
> >>
> >>> Igor Stasenko wrote:
> >>>>>
> >>>>> It makes absolutely no sense to say "oh, we'll all just look it up
> and then
> >>>>> somehow it's going to magically work". Version information is
> *critical* if
> >>>>> you want to play things together in the long term - it has allowed us
> to
> >>>>> have a very smooth ride for a very long time in this area and I wish
> Squeak
> >>>>> would have more of that in general.
> >>>>>
> >>>> Taking a function pointer by name, is nothing more than enumerating
> >>>> the VM capabilities.
> >>>> Take a look at OpenGL extension mechanism. Do they have to change the
> >>>> version of OpenGL each time they want to add new functionality? No.
> >>>> You can simply ask the library about support of certain capability -
> >>>> and depending on answer decide what to do.
> >>>
> >>> Yes, OpenGL is a great example. Because what the OpenGL consortium does
> is moving extensions into core functionality, increasing the version number
> of OpenGL so that clients know they can rely on a documented and stable API.
> Exactly my point.
> >>>
> >>> I have no problems with a named lookup mechanism in addition to a core
> interface. In fact we have one, it's ioLoadFunctionFrom. It solves a useful
> problem, namely that of how to support entry points where you don't know
> whether they will be available in the future or if it's only for use in this
> one version. But it's not a replacement for a documented core API.
> >>
> >>
> >> +1
> >>
> >> But back to the original question - do we want to change the plugin API
> for 4.0 VMs?
> >
> > Yes.  I propose the following changes:
> > - change the interface to the API to one based on function pointers, not
> interpreterProxy.  The function pointers are initialized in a plugin's
> setInterpreter: which does the traditional compatibility check and then
> fetches the function pointers from the argument (exactly how we can discuss
> further).
> > - remove stack access from the API, writing them as SmartSyntaxPlugins
> where arguments are passed in as parameters, returning the result on success
> and 0 (not SmallInteger 0) on failure
> > - eliminate pushRemappableOop/popRemappableOop and make the allocation
> interface one that can fail, so when memory runs out a primitive will return
> an out-of-memory error code
> > - use primitive error codes where appropriate.  e.g. in a plugin
> >     ^self primitiveFailFor: PrimErrNoMem
> > is equivalent to
> >     primErrorCode = 0 ifTrue: [primErrCode := PrimErrNoMem].
> >     ^nil
> > - provide isImmediateObject: and use it in place of isIntegerObject: when
> the objective is to select heap objects.  Use isCharacterObject: when the
> objective is to select a character. I intend to add immediate characters
> within the next few months.
> >
> so, does that means that you will extend the oop tag to 2 bits (or more)?


Yes.  Keep 31-bit SmallIntegers, provide e.g. 24-bit immediate characters.
 Andreas wrote a thorough sketch of this
scheme<http://lists.squeakfoundation.org/pipermail/vm-dev/2006-January/000429.html>in
2006.


> Or just reserve a non-movable heap space for character objects, like:
> isCharacterObject: oop
>  ^ oop >= charsStart and: [ oop < charsEnd ]


No. This doesn't scale to unicode.  The tagged approach provides much faster
string access, and identity comparison for all characters, not just the byte
range.

>
>
>
> >>
> >>
> >> - Bert -
> >>
> >>
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090507/0bef9f06/attachment-0001.htm


More information about the Vm-dev mailing list