| 45 | | The fourth option is possible, but it is unlikely that we will be able to produce a JIT engine as portable, performant, and robust as an existing solution. It is more likely that we can generate a variety of code generators that target all these JITs with less effort then it would take to write our own that works on all our target platform |
| | 45 | The fourth option is possible, but it is unlikely that we will be able to produce a JIT engine as portable, performant, and robust as an existing solution. It is more likely that we can generate a variety of code generators that target all these JITs with less effort then it would take to write our own that works on all our target platform. |
| | 46 | |
| | 47 | == libJIT == |
| | 48 | |
| | 49 | == LLVM == |
| | 50 | |
| | 51 | == Lightning == |
| | 52 | |
| | 53 | Paolo Bonzini, the maintainer of GNU Lightning, has this to say about it: |
| | 54 | |
| | 55 | - Current status: Mature. It serves its purpose well and since there is no incentive and contributors to write new backends, I'm just fixing bugs. An ARM backend is the only one that is really missing. |
| | 56 | - Stable releases: Just use the latest git tree. The code is stable enough that right now using git is better. |
| | 57 | - Support policy: Best effort. Write email and I'll do my best to fix bugs and publish the fixes as soon as possible; all I expect you to do is to include the miscompiled code's disassembly (i.e. I won't install Parrot). On the other hand, the code is quite small and easy to understand. Most of the contributors came out with patches of their own, that we then developed together. |
| | 58 | - Project Viability: The project is viable if all you care about is x86 (32/64 bit), SPARC (32-bit only), PPC (32-bit only). It is very lightweight and favors fast compilation over fast execution (though I still got 3-4x improvement over a very optimized bytecode interpreter). |
| | 59 | |
| | 60 | "If this is what you want, go for it; I don't think lightning will disappoint you. If you want slow but optimized code generation, register allocation, and the like, I'd say use LLVM instead." |
| | 61 | |
| | 62 | Pros: fast code generation, stable codebase |
| | 63 | Cons: slow generated code execution, limited platform support and not enough developer momentum to add new platforms. |
