[Pharo-project] sqInt setCompilerInitialized(sqInt newFlag)
Does anybody have an idea what is the purpose of this function in the vm? Stef sqInt setCompilerInitialized(sqInt newFlag) { register struct foo * foo = &fum; sqInt oldFlag; oldFlag = foo->compilerInitialized; foo->compilerInitialized = newFlag; return oldFlag; }
Hi Stéf, it is an initializer for the old jitter VM. 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). On Fri, Feb 18, 2011 at 12:21 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Does anybody have an idea what is the purpose of this function in the vm?
Stef
sqInt setCompilerInitialized(sqInt newFlag) { register struct foo * foo = &fum; sqInt oldFlag;
oldFlag = foo->compilerInitialized; foo->compilerInitialized = newFlag; return oldFlag; }
Tx
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.
On Fri, Feb 18, 2011 at 12:21 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Does anybody have an idea what is the purpose of this function in the vm?
Stef
sqInt setCompilerInitialized(sqInt newFlag) { register struct foo * foo = &fum; sqInt oldFlag;
oldFlag = foo->compilerInitialized; foo->compilerInitialized = newFlag; return oldFlag; }
On 20 February 2011 08:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Tx
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 specific order. 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 work. So, this means that pluign don't needs to be bound to VM version anymore. -- Best regards, Igor Stasenko AKA sig.
Sig, 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. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, February 20, 2011 11:42 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] sqInt setCompilerInitialized(sqInt newFlag) On 20 February 2011 08:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Tx
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 specific order. 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 work. So, this means that pluign don't needs to be bound to VM version anymore. -- Best regards, Igor Stasenko AKA sig.
participants (4)
-
Eliot Miranda -
Igor Stasenko -
Schwab,Wilhelm K -
Stéphane Ducasse