4 JITCS a.k.a. Just-In-Time-Compiler-System will become a just-in-time assembler
5 on all platforms where this service is plausible (e.g. Windows, MacOS X, Linux,
6 and Android, but NOT iOS or Windows Phone). Usage is targeted at applications
7 where compilation speed and code quality are both important, e.g. emulation.
9 JITCS is Copyright (C) 2013-2014 Dirk Steinke.
10 JITCS is free software, released under the MIT license.
11 See full Copyright Notice in the COPYRIGHT file or in include/jitcs.h.
13 WARNING: The library is currently not fit for ANY purpose, and is severely
14 lacking documention. You MAY study its general design principles, but
15 unfortunately, the most interesting parts are still to come.
17 The goals of JITCS are simple:
18 - require minimal overhead
19 - provide fast compilation time
20 - provide good code quality
21 - generate as much target dependent source code as possible from data
23 - be available on all platforms supporting JIT compiling
25 Concerning multithreading: JITCS is reentrant, so different compiler objects
26 can be used by different threads, BUT JITCS is not using mutexes for anything,
27 so DO NOT share a compiler object across threads unless you do the
28 synchronizaton yourself.
30 At the moment, the scope of JITCS is limited to JIT assembly. There are three
31 subproblems concerning assembly: instruction selection, instruction scheduling
32 and register selection.
33 - Instruction selection: the type of operation is in most cases already
34 determined by the code developper (e.g. addition or multiplation), and most
35 of the time also the data on which the operation is working (e.g. int, float
37 Using an IR to abstract from the actual hardware makes hardly sense in a
38 situation where the target hardware is mostly already determined (e.g. x86 on
39 Windows/Linux, ARM on Android/iOS). Due to its abstract nature, IR is better
40 suited for instruction combining, especially on 32-bit ARM, where many shift
41 instructions can be combined with arithmetic or logical operations.
42 The JITCS assembly stage assumes, that the best possibly instruction for the
43 current operation has already been selected.
44 - Instruction scheduling: while out-of-order architectures like x86 and modern
45 ARM do not benefit as greatly as older architectures from latency-based
46 scheduling, there are cases where they do. on the other hand, latency and
47 port-usage differs greatly between different versions of x86 for the same
48 instruction. so a JIT assembler should MEASURE the current architecture's
49 instruction latencies and port-usage, and NOT rely on built-in tables.
50 While there are ideas, on how to achieve that, JITCS just assumes that the
51 out-of-order target architecture will do the job good enough.
52 - Register selection: register allocation is basically a caching scheme.
53 Concerning the latencies for memory accesses (especially, if the memory is
54 NOT in L1 cache), it is good practice to avoid having to reload registers
55 from memory more often than necessary. If the exact size of the available
56 register file is not known to the code developper, or if he DOES NOT WANT to
57 worry about it, a good assembler should provide for a reasonably good
58 allocation scheme. Of course, the better the scheme, the longer the required
60 JITCS will provide for several levels of allocation quality. NONE of them
61 will beat the allocation quality of gcc or LLVM, but the best level should be
62 at least close, while still taking less time.
64 To do a good job on register allocation for native instructions, JITCS provides
65 data files describing all necessary information required for any native
66 instruction to be handled by JITCS. During the build process, these data files
67 are transformed into C++ source code meant to handle the native instructions.
68 The required information for each instruction comprises:
69 - type and names of parameters (for instruction constructors)
70 - usage of register parameters : used and/or defined (for dataflow analysis)
71 - usage of implicit registers (e.g. EFLAGS on x86, for dataflow analysis)
72 - ISA requirements (to test if a certain instruction can be run on the current
74 - description of instruction encoding (to turn the instruction object into
76 - operand folding (e.g. folding a memory load operation into a
77 register-register operation on x86)
81 Concerning just-in-time compilation, there are several alternatives available.
84 It is a very fast, directly encoding, just-in-time assembler for x86 with
85 minimal overhead. The user is responsible for choosing instruction,
86 scheduling and registers.
87 The Library is header files only.
89 A just-in-time compiler based on the popular LLVM library. It provides target
90 independence, a full-fledged optimization support, superior code generation
91 and a vast developper community.
92 Disadvantages are a rather low compilation speed and large library
93 dependencies (several megabyte).
95 X86. Instructions are temporarily stored with their operands, before the
96 machine code is generated in the second phase. It does not provide help with
97 instruction selection or scheduling, but offers help with register selection
98 (a.k.a. allocation). The allocator uses a rather naive scheme, and needs help
99 for good code generation.
100 The Library size is small (maybe 100-200k?).
102 JITCS resembles in design AsmJit. It is slower than xbyak, and produces worse
103 code than LLVM. JITCS will employ a much more sophisticated register allocator