 |
Related: 0003623 |
 |
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: http://cseweb.ucsd.edu/~jvoung/llvm_size_report/ And here it is explained how "get started" with it: http://llvm.org/docs/GettingStartedVS.html (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. https://github.com/asmjit/asmjit 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. |
- Anonymous
