Seeing how LLVM can port its bytecode into asm.js, wouldn't it be better to target LLVM and get free JS conversion to near native speeds? This allows fcode to be translated directly into JS instead of having to rely on source code transformations.
IIRC LLVM support was pending on having Int32, Int16, Int8 and unsigned versions in core, right? That would probably help with low level applications and designing for Android.
brianThu 18 Apr 2013
I like the idea, but it would make the tool chain a lot more complicated to use versus having everything in Fantom like we have it now and just need a JVM to do everything.
DanielFath Thu 18 Apr 2013
Seeing how LLVM can port its bytecode into asm.js, wouldn't it be better to target LLVM and get free JS conversion to near native speeds? This allows fcode to be translated directly into JS instead of having to rely on source code transformations.
IIRC LLVM support was pending on having Int32, Int16, Int8 and unsigned versions in core, right? That would probably help with low level applications and designing for Android.
brian Thu 18 Apr 2013
I like the idea, but it would make the tool chain a lot more complicated to use versus having everything in Fantom like we have it now and just need a JVM to do everything.