[Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)
bschwab at anest.ufl.edu
Sun Feb 20 18:05:04 CET 2011
You mean it doesn't work that way already?? :) It sounds good. Does the name lookup proceed by dlsym()/GetProcAddress()/etc.? The alternative would be to have a map inside the vm that would require maintenance :( The other question is how often does the lookup occur? It's probably not a concern, but it deserves at least a quick thought.
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua at gmail.com]
Sent: Sunday, February 20, 2011 11:42 AM
To: Pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)
On 20 February 2011 08:59, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>> Hi Stéf,
>> it is an initializer for the old jitter VM.
> which one?
> The one that marcus worked on with Ian in 2001?
>> It is not used and simply set to zero in the Cog VMs. It is still included in sqVirtualMachine.c because that's the way that interface works (that VirtualMachine is a struct of function pointers).
> I did not get it.
the virtual machine public interface is a list of function pointers in
You can't remove something from list, otherwise it will become
non-compatible with older versions.
Therefore you can only add new function pointers to the end of list.
The problem is that plugin assuming that if VM has greater version
than it was compiled once, its API is backwards compatible.
I think we should move away from this binding, and use name lookup
mechanism, which i implemented in Hydra.
Plugin just asks VM for providing a function with given name. If there
is no such function, plugin will fail to initialize and refuse to
So, this means that pluign don't needs to be bound to VM version anymore.
Igor Stasenko AKA sig.
More information about the Pharo-project