/* Comparison ops. ORDER OPR. */ \
_(ISGT,
var,
___,
var,
le) \
...
總之就是充斥著各種拼接起來的宏
lj_ffdef.h:
1 FFDEF(assert)
2 FFDEF(type)
3 FFDEF(next)
4 FFDEF(pairs)
5 FFDEF(ipairs_aux)
6 
FFDEF的定義是在
1 /* Fast function ID. */
2 typedef enum {
3 FF_LUA_ = FF_LUA, /* Lua function (must be 0). */
4 FF_C_ = FF_C, /* Regular C function (must be 1). */
5 #define FFDEF(name) FF_##name,
6 #include "lj_ffdef.h"
7 FF__MAX
8 } FastFunc;
差不多就是用FF_##name把上面的名字拼接起來，然后生成在enum里面，這樣就能當(dāng)成是數(shù)字，在數(shù)組中迅速找到入口了
vmdef.lua:
這個(gè)里面內(nèi)容就不貼了，包括bcname,irname,irfpm,irfield,ircall 的定義，在jit文件夾下面，用于調(diào)試等，比如在dump.lua中就有用到
local jit = require("jit")
assert(jit.version_num == 20002, "LuaJIT core/library version mismatch")
local jutil = require("jit.util")
local vmdef = require("jit.vmdef") // ← ← ← ←
當(dāng)你用luajit -jdump的時(shí)候，就是調(diào)用的lua的jit庫里面的lua函數(shù)
lj_recdef.h:
1 static const uint16_t recff_idmap[] = {
2 0,
3 0x0100,
4 0x0200,
5 0x0300,
6 0,
7 0,
8 0x0400,
9 10 };
11 12 static const RecordFunc recff_func[] = {
13 recff_nyi,
14 recff_c,
15 recff_assert,
16 recff_type,
17 recff_ipairs_aux,
18 19 };
其中recff_func[]是被注冊(cè)的被traced jit 跟蹤的函數(shù)，具體可是在lj_ffrecord.c里面看到
recff_idmap[]被用在lj_ffrecord_func這個(gè)函數(shù)中，有一個(gè)關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)RecordFFData，用來記錄在trace過程中被調(diào)用函數(shù)的參數(shù)和返回值個(gè)數(shù)，和一些輔助數(shù)據(jù)，opcode，literal等等。通過recff_idmap[]保存的值來區(qū)分函數(shù)（待仔細(xì)研究）
lj_folddef.h:
1 static const FoldFunc fold_func[] = {
2 fold_kfold_numarith,
3 fold_kfold_ldexp,
4 fold_kfold_fpmath,
5 fold_kfold_numpow,
6 7 };
8 9 static const uint32_t fold_hash[916] = {
10 0xffffffff,
11 0xffffffff,
12 0x5b4c8016,
13 14 };
用在FOLD optimization中，見lj_opt_fold.c，主要在
1 if ((fh & 0xffffff) == k || (fh = fold_hash[h+1], (fh & 0xffffff) == k)) {
2 ref = (IRRef)tref_ref(fold_func[fh >> 24](J));
3 if (ref != NEXTFOLD)
4 break;
5 }
是根據(jù)數(shù)組偏移獲取函數(shù)，直接執(zhí)行。
（這個(gè)Optimation略復(fù)雜，以后的博文中再說）
----------------------------------------分割線-------------------------------------------
以上就是buildvm生成代碼，在很多.c的文件中，他加入了一些無意義的MARCO，目的是為了能被buildvm識(shí)別出
下面說說src根目錄下面的文件：
lauxlib.h：
用戶開發(fā)擴(kuò)展和與C交互的時(shí)候的頭文件
lib_*.h /.c:
顧名思義，就是利用LuaAPI寫的內(nèi)部標(biāo)準(zhǔn)庫，會(huì)在方法上表明是否會(huì)被trace ( LJLIB_REC(.) )。
ljamalg.c:
文件的合并
lj_alloc.h /.c:
定制的Memory Allocator
lj_api.c:
Public Lua/C API.
lj_arch.h:
Target architecture selection
lj_jit.h:
jit編譯器里面數(shù)據(jù)結(jié)構(gòu)的定義
lj_asm.h/ .c lj_asm_*.c lj_emit_*.h lj_target_*.h/.c :
將IR編譯成Machine Code，關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)ASMState，線性掃描的O(n2)分配算法
lj_bc.h/ .c：
Luajit字節(jié)碼的定義和內(nèi)存布局
lj_bcdump.c lj_bcread.c lj_bcwrite.c:
圍繞著字節(jié)碼的操作
lj_carith.c:
C實(shí)現(xiàn)的一些數(shù)字運(yùn)算
lj_ccall.h/ .c lj_ccallback.h / .c :
FFI C語言函數(shù)調(diào)用和回調(diào)綁定
lj_debug.h/.c :
調(diào)試與自省用
lj_def.h:
這個(gè)很重要，重要的類型和一些宏定義在這里
lj_c*.h/ .c:
和C語言先關(guān)的，比如類型轉(zhuǎn)化，char管理，數(shù)據(jù)管理
lj_frame.h:
Luajit的棧幀管理
lj_func.h/.c:
Function handle和閉包有關(guān)的upvalue數(shù)據(jù)結(jié)構(gòu)
lj_gc.h/.c:
GC相關(guān)，GC可以看下luajit的wiki，里面涉及不少增量式GC的paper和作者的看法
lj_gdbjit.h/.c :
對(duì)gdb的支持
lj_ir*.h/.c:
SSA，IR相關(guān)（這個(gè)和bytecode還是不一樣的）操作和優(yōu)化
lj_lex.h/.c lj_parse.h/.c:
lexer和parser
lj_mcode.h/.c:
Machine Code管理
lj_opt_*.h:
各種bytecode層面上的優(yōu)化
lj_snap.h/.c:
快照支持
lj_state.h/.c:
LuaState和Stack的操作
lj_str*.h/.c lj_tab.h/.c:
原生類型string和table操作
lj_udata.h/.c:
類型user data的操作
lj_vm.h/.c lj_vmevent.h/.c:
vm的API和事件注冊(cè)（lj_vmevent_send）
lj_vmmath.h/.c：
對(duì)vm支持的math庫
lua.h:
luaState等基本的Lua結(jié)構(gòu)
lualib.h:
和Lua一樣，標(biāo)準(zhǔn)庫的API
luajit.h:
luajit 的public API
vm_*.dasc:
編譯期被DynASM預(yù)處理的源文件，下一篇講DynASM時(shí)候介紹dasc文件
wmain.c:
windows下面的main入口
和Trace相關(guān)的：
lj_crecord.h/.c ： C操作的trace record
lj_dispatch.h/.c : 指令分發(fā)，調(diào)用ASMFuction，處理指令前的hook和記錄trace用的hot count，有一個(gè)重要的數(shù)據(jù)結(jié)構(gòu) GG_State
lj_ff*.h/.c: 上面講lj_ffdef.h的時(shí)候提過，trace的時(shí)候 記錄Fast Function的調(diào)用記數(shù)
lj_trace.h/.c: trace的具體過程
lj_traceerr.h : trace error