Unofficial HashLink thread

583 views
Skip to first unread message

Justin Donaldson

unread,
Oct 21, 2016, 12:18:29 PM10/21/16
to Haxe
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.

Where does this leave the macro runtime?  Can this be handled through an HL backend now?

What does the FFI look like?  Will there be anything special for HL since it is so closely tied to C?

What were some of the design differences between HL and Neko?  I.e. what was learnt between the targets?



 

Nicolas Cannasse

unread,
Oct 21, 2016, 3:23:00 PM10/21/16
to haxe...@googlegroups.com
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

der Raab

unread,
Oct 26, 2016, 3:14:23 AM10/26/16
to Haxe
I'd like to add just a noob question: What's the main difference between hl c / JIT and the usage of cpp / cppia? Is this in any way comparable or just not. And is hl c as fast / faster than hxcpp?

Adrian Veith

unread,
Oct 26, 2016, 3:39:45 AM10/26/16
to Haxe


Am Freitag, 21. Oktober 2016 21:23:00 UTC+2 schrieb Nicolas Cannasse:
Le 21/10/2016 à 18:18, Justin Donaldson a écrit :
> Congrats to Nicolas on the new target!
 
> 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


- Is it possible to load one or more HL bytecode modules from inside a HL/C Application ? 
- can a HL bytecode module run on a different thread ?
- is the GC threadsafe or running on a single thread ?

I am thinking of Application Server like scenarios, or using HL bytecode modules inside a database server for user defined functions etc.

best Adrian.
 

Cambiata

unread,
Oct 26, 2016, 1:45:47 PM10/26/16
to Haxe
Check Nicola's London speach: https://www.youtube.com/watch?list=PLf_LHaO6nZF6ew1RWyv8dhsBIEkdC6wa9&v=wjv7hbN7sHE
At 39:30 he's explaining the differences.

Nicolas Cannasse

unread,
Oct 26, 2016, 3:39:14 PM10/26/16
to haxe...@googlegroups.com
> - Is it possible to load one or more HL bytecode modules from inside a
> HL/C Application ?

ATM the JIT is only bundled with hl "vm", not with HL/C runtime, but it
should be possible to expose the VM API to allow an HL/C runtime to
load+run HL/JIT code, both should be mutually interoperable.

> - can a HL bytecode module run on a different thread ?
> - is the GC threadsafe or running on a single thread ?

ATM the GC is single thread only, I'm planning to work on multithread
support later, it's not a huge change but requires some extra code in
order to prevent blocking on some system I/O operations.

Best,
Nicolas

Rafael Oliveira

unread,
Nov 10, 2016, 11:06:54 AM11/10/16
to Haxe
What means exactly the SDL support? The library will be available to import, like this
import hl.SDL; ?

Nicolas Cannasse

unread,
Nov 10, 2016, 12:19:57 PM11/10/16
to haxe...@googlegroups.com
Le 10/11/2016 à 17:06, Rafael Oliveira a écrit :
> What means exactly the SDL support? The library will be available to
> import, like this
> import hl.SDL; ?

Yes, see:
https://github.com/HaxeFoundation/hashlink/tree/master/libs/sdl/sdl

Don't worry that some methods are not implemented, it's because they are
imported from C (@:hlNative metadata in class)

Nicolas
Reply all
Reply to author
Forward
0 new messages