C JIT Compilation? Really?

[Mike Lobanovsky]

John,

Since when is ScriptBASIC able to JIT compile C code?

[JRS]

Thanks! Corrected to JIT O2 code not C.

Maybe I was thinking about that CERN ROOT as a DLL ext. module as the JIT C option. 

Does SB's ability to create C executables from scripts carry any weight?

[JRS]

Just-In-Time Compilation (libgccjit.so)

This project aims aims to provide an embeddable shared library with an API for adding compilation to existing programs using GCC as the backend:libgccjit.so.

This shared library can then be dynamically-linked into bytecode interpreters and other such program

JIT-GCC Wiki

[Mike Lobanovsky]

Judging by their wiki's samples, this is not C code. This is some ugly-looking intermediate language that resembles C very distantly. Seems like they aren't fully aware of either what or how to do it, at least at this alpha stage.

Does SB's ability to create C executables from scripts carry any weight?

Do you mean translation of SB scripts to equivalent C?

[JRS]

Thanks Mike for the feedback. I won't waste any time with it.

[JRS]

Do you mean translation of SB scripts to equivalent C?

No. More like how VB classic creates executables with binary PCODE and a runtime shared object. (DLL/so)

OT: Here is my 2222 post. You had your 1111 post not too long ago.

[Mike Lobanovsky]

I think this is a natural feature in a BASIC that has some form of "compilation" functionality. E.g. FBSL can generate "executables" in two forms: i) completely standalone ones that carry the entire runtime in themselves; or ii) "tiny" exes that have a 1.5KB program launcher only and the rest is provided by Fbsl.dll. (in fact, similar to Oxygen) If this is what you mean by "creation of C executables" then I don't see anything unusual in it.

But both of these FBSL exe forms use a human readable script rather than its bytecode representation. The script is reparsed and byte coded at app start. The FBSL parser is fast enough to do it in negligeable time. Storage and interpretation of bytecode image might be a step forward towards better optimization but I don't see any insentive in doing so in FBSL. E.g. a 100KB script with BASIC, C and asm blocks starts in less than 50 milliseconds, i.e. practically instantly, as it is.

I think "to bytecode or not to bytecode" at app start really depends on your estimation of how efficient a language's existing parser and byte coder/JIT compiler is.

P.S. Congrats! Looking forward to your 3333rd one.

[JRS]

"to bytecode or not to bytecode"

SB won't run a script that isn't syntactically correct. SB can run from a cache directory of pre-tokenized scripts. This is normally done on a production application server of sbhttpd. It gets in the way while in development and not worth the millisecond of time that might be saved. ODBC connection pooling is another web performance feature the sbhttpd server supports.

SB .exe programs require about 25KB of interface C code and the rest is script tokenized byte code.