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).


-- 
Best regards,
Igor Stasenko.