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

[Igor Stasenko]

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)?
Or just reserve a non-movable heap space for character objects, like:
isCharacterObject: oop
 ^ oop >= charsStart and: [ oop < charsEnd ]


>>
>>
>> - Bert -
>>
>>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.