[NativeBoost] new win32 build available

Hello,

i just uploaded a new VM, i built tonight and new NativeBoost code.
VM is built from latest SVN + VMMaker + NativeBoostPlugin sources, and
now NativeBoost can use all latest additions to interpreterProxy
function table,
such as addGCRoot, stackPointer etc.

And there's already a code which using that, named NBExternalTypeRegistry.
It serves as a dictionary of  name->object values, where you can
register any object under given name
and then use it in native code (during native code generation).

This is analoguous to what SpecialObjectArray serving for, where you
can put an object and then use that object in primitives
through well-known index.
But in contrast to SpecialObjectArray, a NBExternalTypeRegistry
doesn't requires from you to use indexes. You can use just names!
Also, it doesn't requires from you to statically assign or initialize
the same set of name/value pairs at each image startup.

All what you need is just register an object first:

NBExternalTypeRegistry current at: #MyName put: #(10 12 13)

and then, in your assembler, emit code to load it:

NBExternalTypeRegistry current emitOopAt: #MyName generator: gen


When your restarting a VM, it makes sure that this registry are
initially clean.
So, it is get refilled only when some new native methods is generated
which are using registry to fetch some named object(s).

The most often use of named objects is, of course, instantiating the
objects of specific class, like:

self typeRegistry emitFetchClass: objectClass generator: gen.
proxy instantiateClass: asm EAX indexableSize: 0.

Or, checking that argument is of correct type.
Here, the method which generates a code to verify that argument class
(held in oop) will be an objectClass:

validateClassOf: oop generator: gen

        | asm class |
        asm := gen asm.
        class := gen reserveTemp.
       
        gen proxy fetchClassOf: oop.
        asm mov:  asm EAX to: class.
       
        self typeRegistry emitFetchClass: objectClass generator: gen.
       
        asm cmp: asm EAX with: class;
                jne: gen failedLabel.
       
        gen releaseTemps: 1.


--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Core packages were broken, and were unable to load w/o errors.
But now seems everything loads well.
Use NBInstaller install.

Thanks to Henrik for help!


--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

  On 29.04.2010 17:13, Igor Stasenko wrote:
> Core packages were broken, and were unable to load w/o errors.
> But now seems everything loads well.
> Use NBInstaller install.
>
> Thanks to Henrik for help!
Here's a small example, as well as profile:

SmallInteger >> nbFib
<primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'>
     ^ NBNativeCodeGen methodAssembly: [:gen |
         | loopStart proxy asm  EAX EBX ECX |
         asm := gen asm.
         proxy := NBInterpreterProxy new asm: asm.
         loopStart := asm uniqueLabelName: 'loopStart'.

         EAX := asm assembler reg0.
         EBX := asm assembler reg3.
         ECX := asm assembler reg1.
         proxy receiver.
         proxy integerValueOf: EAX.

         asm mov: EAX to: ECX;
                 mov: 0 to: EAX;
                 mov: 1 to: EBX;
                 label: loopStart;
                 add: EAX with: EBX;
                 xchg: EAX with: EBX;
                 "next three could be replaced by loopnz and a dec ECX
before loop, but loopnz isn't there yet"
                 dec: ECX;
                 cmp: ECX with: 1;
                 jg: loopStart.

         proxy positive32BitIntegerFor: EBX.
         gen epilogue]

SmallInteger >>fib
     |tmp res|
     tmp := 1.
     res := 0.
     0 to: self -1 do: [:ix | |oldRes|
             oldRes := res.
             res := tmp + res.
             tmp := oldRes.].
     ^res

Neither work for negative integers, and nbFib overflows for 48, haven't
added largeInt creation logic :)

[1 to: 100000 do: [:ix | 47 fib]] timeToRun 361
[1 to: 100000 do: [:ix | 47 nbFib]] timeToRun 21
[1 to: 100000 do: [:ix | ]] timeToRun 2

Cheers,
Henry




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Interesting.  Scary<g> but interesting.  At the risk of seeming obsessed with numerical analysis, is there a way to use this for callbacks?

Bill


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 30 April 2010 01:54, Henrik Sperre Johansen
<[hidden email]> wrote: ohh.. you will be need more than just create large int.
Since at 48 you will get past the size of register, you'll have to
switch to different loop.
And it will end up with quite complex assembler :)

But if we leave the complexity aside, the thing is, that you can
greatly optimize it comparing to
smalltalk implementation.
You can use stack, for keeping a variable-length big int during calculation.
So, you will need to create a single final BigInt oop only when loop ends.



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 30 April 2010 02:16, Schwab,Wilhelm K <[hidden email]> wrote:
> Interesting.  Scary<g> but interesting.  At the risk of seeming obsessed with numerical analysis, is there a way to use this for callbacks?
>
Not yet. But i plan to add the callbacks support.

> Bill
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project