On 12-08-19 6:26 PM, Igor Stasenko wrote:
> On 17 August 2012 22:21, Yanni Chiu <yanni at rogers.com> wrote:
>> On 17/08/12 2:46 PM, Lawson English wrote:
>>>
>>> Which is a huge downside to the current implementation of NativeBoost,
>>> although, in theory, you could create a version that would compile to C
>>> via slang rather than using Igor's x86 assembler syntax.
>>
>> But it's called *Native*Boost. Are you suggesting non-native boost? Wouldn't
>> that be Cog/JIT?
>>
> Right. It is native. You can talk directly to metal. No layers on
> top.. you are the in total control.
> This is the main motivation behind a project.
> You can build abstractions on top of it, of course. And of course you
> can make it portable across
> as many platforms as you need.. It may be hard but it is doable.
> But conceptually one thing are not gonna change: you have direct
> access to machine code,
> which means no compiler standing in your way, which generating
> suboptimal code :)
> And for some cases it is simply impossible to implement things in C
> without heavy sacrifices in speed..
> consider arithmetic overflow - in CPU's you have a flag which indicates that..
> but in C there is no way how you can access it.. so you cannot just write:
>
> int a, b;
> if ( (result = a +b) > maxInt )
> {
>   .. switch to big integer arithmetic ..
> }
>
> and i guess you can find many other cases where direct machine code is
> more preferable than produced by compiler(s).
>
>
In the last few posts you just wrote as many words arguing for 
NativeBoost as David did explaining how to get started writing a plugin. 
Except when he was done a person could actually start to write a plugin. 
If you and Lawson spent as much time providing examples for NativeBoost 
as you do extolling its virtues, I could actually try it for myself.

Chris