View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003793||The Dark Mod||Feature proposal||public||22.07.2014 18:41||01.09.2020 17:31|
|Priority||normal||Severity||normal||Reproducibility||have not tried|
|Summary||0003793: Replace script interpreter with a JIT implementation|
|Description||Currently, all script events are interpreted from text in real-time rather than|
being pre-compiled as binary. Quake 3 had a JIT compiler for scripts and it improved performance as well as script debugging.
these hook into msvc2010 through 2013 so you can use clang with msvc.
|Tags||No tags attached.|
I don't think using LLVM is wise.
It is a huge, constantly changing, windows unfriendly project, do you really think it is OK to depend on it?
Here is a bit about how large it is:
And here it is explained how "get started" with it:
(it is mentioned there that at least MSVC2015 is required)
Also, the simplest way to implement JIT-compiler is to translate bytecode into native code. In order to get better error reports, it is necessary to change the frontend, i.e. add better error diagnostocs to ID's compiler. How can LLVM help with it?
You might be dreaming of replacing ID's compiler with Clang, but I'm pretty sure that even slightest differences between doom3 scripting language and clang would be almost impossible to fix in the huge clang codebase.
If we need better performance for scripts execution, then it is possible to compile them into native code on initialization.
Carmack implemented such compilation for Quake 3 in several days. He wrote templates manually, writing down binary x86 code in hex representation.
In our case, we should support x86/x64 differences, and MSVC/GCC + windows/linux. The asmjit library can help here: it allows to write single code to support all of these cases. And it is not so big and tricky.
Writing compiler to native code is as simple as providing assembly code (well, in C++-wrapped form) for all 123 opcodes of the interpreter. Indeed, the resulting binary would not be optimal (LLVM could do better), but do we need utmost performance of scripts?
|Yes good points on LLVM. That's probably more of a quagmire than our current boost dependency mess.|
|I think doing anything for this issue does not make sense unless there is any evidence that improving script performance would make game run noticeably faster. Currently I doubt it greatly.|
|22.07.2014 18:41||nbohr1more||New Issue|
|22.07.2014 18:43||nbohr1more||Note Added: 0006792|
|29.04.2017 01:54||nbohr1more||Assigned To||=> stgatilov|
|29.04.2017 01:54||nbohr1more||Status||new => acknowledged|
|29.04.2017 01:54||nbohr1more||Target Version||=> TDM 2.06|
|29.04.2017 05:01||stgatilov||Note Added: 0008811|
|29.04.2017 05:09||stgatilov||Note Added: 0008812|
|30.04.2017 00:28||nbohr1more||Summary||Replace script interpreter with a JIT implementation using LLVM => Replace script interpreter with a JIT implementation|
|30.04.2017 00:30||nbohr1more||Note Added: 0008814|
|08.08.2017 17:03||stgatilov||Note Added: 0009067|
|08.08.2017 17:03||stgatilov||Target Version||TDM 2.06 =>|
||Relationship added||related to 0003623|
|31.08.2020 04:13||stgatilov||Assigned To||stgatilov =>|
|31.08.2020 04:14||stgatilov||Assigned To||=> stgatilov|
|31.08.2020 04:14||stgatilov||Status||acknowledged => suspended|
|01.09.2020 17:31||stgatilov||Assigned To||stgatilov =>|