Le 21/10/2016 à 18:18, Justin Donaldson a écrit :
> Congrats to Nicolas on the new target!
>
> This sure seems like a great idea, a runtime that's tuned specifically
> to the language, with both a c and a JIT target.
>
> I had a few questions:
>
> Where does this leave Neko? HL seems to eclipse it in meaningful ways.
NekoVM has not seen much changes in the past years, we will continue
supporting it together with HashLink in Haxe.
> Where does this leave the macro runtime? Can this be handled through an
> HL backend now?
Unless we use a JIT it does not seem like a good idea, but interpreted
HL code might be slower than interpreted Neko code.
> What does the FFI look like? Will there be anything special for HL
> since it is so closely tied to C?
You can have a look at FFI example here:
https://github.com/HaxeFoundation/hl/blob/master/libs/fmt/fmt.c
And Haxe API:
https://github.com/HaxeFoundation/haxe/blob/development/std/hl/Format.hx
> What were some of the design differences between HL and Neko? I.e. what
> was learnt between the targets?
Neko uses a stack based dynamically typed bytecode.
HL uses a register based strictly typed bytecode. This allows to ensure
bytecode correctness at compile time, and apply significant
optimizations at runtime. It also can use native types such as double or
full 32 bits integers without need from "boxing" (allocating a block of
memory that holds the value).
Best,
Nicolas