On 21 March 2011 02:43, Levente Uzonyi <[email protected]> wrote: > On Sun, 20 Mar 2011, Igor Stasenko wrote: > >> Hello, >> i just wanna to inform you that i adopted NativeBoost plugin for >> building with latest Cog vms. > > Great. > >> >> To build VM, you should have an image with VMMaker + CMakeVMMaker >> packages installed. >> >> Then load NBIntaller package and do: >> NBInstaller installCogPlugin >> >> There are new cmake configurations i added to build VMs with NB plugin >> support. > > It's an old question, but I don't remember your answer, so: wouldn't it > be better to add a command line switch for enabling NB? So even if a VM is > compiled with NB, I can still turn it off if I want to. >
It is disabled by default, when you starting a new image. This allows me to not care if some of the methods were carrying native code saved into an image. For enabling a native code, one should invoke #primitiveEnable first. You can customize a mechanism of enabling it in NativeBoost class>>enableNativeCode and put checking of command-line argument(s) there. And yes, i am against putting extra logic at plugin side :) The reason is simple: if you using it, then you know what you doing, and if you don't - then you safe anyways. Also, plugin can be made external, if you want. But there is certainly some intimate connection with VM, so i wouldn't recommend making it external, because it can easy break things, if you mismatch VM/plugin pairs. I am also looking forward for making JITted code to make direct calls to NB native code. In a way, that JIT code would not call #primitiveNativeCall (and only then enter native code) but instead directly call the native code which method contains. It will , of course, bypass all logic placed in #primitiveNativeCall, like checking if NB is enabled etc.. and could be dangerous.. but the speed will be... :) In a longer perspective this means that eventually JIT compiler could be moved from VM to language side (like Exupery does). -- Best regards, Igor Stasenko AKA sig.
