[Vm-dev] mantis http://bugs.squeak.org/view.php?id=7349
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
>>>> somehow it's going to magically work". Version information is *critical*
>>>> 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
>>>> 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.
> 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
- 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].
- 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...
More information about the Vm-dev