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

Eliot Miranda eliot.miranda at gmail.com
Thu May 7 16:04:54 UTC 2009


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.



>
> - Bert -
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090507/bb88c588/attachment.htm


More information about the Vm-dev mailing list