On 21 March 2011 02:43, Levente Uzonyi <leves at elte.hu> 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.