/* 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里面，這樣就能當成是數字，在數組中迅速找到入口了
vmdef.lua:
這個里面內容就不貼了，包括bcname,irname,irfpm,irfield,ircall 的定義，在jit文件夾下面，用于調試等，比如在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") // ← ← ← ←
當你用luajit -jdump的時候，就是調用的lua的jit庫里面的lua函數
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[]是被注冊的被traced jit 跟蹤的函數，具體可是在lj_ffrecord.c里面看到
recff_idmap[]被用在lj_ffrecord_func這個函數中，有一個關鍵的數據結構RecordFFData，用來記錄在trace過程中被調用函數的參數和返回值個數，和一些輔助數據，opcode，literal等等。通過recff_idmap[]保存的值來區分函數（待仔細研究）
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 }
是根據數組偏移獲取函數，直接執行。
（這個Optimation略復雜，以后的博文中再說）
----------------------------------------分割線-------------------------------------------
以上就是buildvm生成代碼，在很多.c的文件中，他加入了一些無意義的MARCO，目的是為了能被buildvm識別出
下面說說src根目錄下面的文件：
lauxlib.h：
用戶開發擴展和與C交互的時候的頭文件
lib_*.h /.c:
顧名思義，就是利用LuaAPI寫的內部標準庫，會在方法上表明是否會被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編譯器里面數據結構的定義
lj_asm.h/ .c lj_asm_*.c lj_emit_*.h lj_target_*.h/.c :
將IR編譯成Machine Code，關鍵的數據結構ASMState，線性掃描的O(n2)分配算法
lj_bc.h/ .c：
Luajit字節碼的定義和內存布局
lj_bcdump.c lj_bcread.c lj_bcwrite.c:
圍繞著字節碼的操作
lj_carith.c:
C實現的一些數字運算
lj_ccall.h/ .c lj_ccallback.h / .c :
FFI C語言函數調用和回調綁定
lj_debug.h/.c :
調試與自省用
lj_def.h:
這個很重要，重要的類型和一些宏定義在這里
lj_c*.h/ .c:
和C語言先關的，比如類型轉化，char管理，數據管理
lj_frame.h:
Luajit的棧幀管理
lj_func.h/.c:
Function handle和閉包有關的upvalue數據結構
lj_gc.h/.c:
GC相關，GC可以看下luajit的wiki，里面涉及不少增量式GC的paper和作者的看法
lj_gdbjit.h/.c :
對gdb的支持
lj_ir*.h/.c:
SSA，IR相關（這個和bytecode還是不一樣的）操作和優化
lj_lex.h/.c lj_parse.h/.c:
lexer和parser
lj_mcode.h/.c:
Machine Code管理
lj_opt_*.h:
各種bytecode層面上的優化
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和事件注冊（lj_vmevent_send）
lj_vmmath.h/.c：
對vm支持的math庫
lua.h:
luaState等基本的Lua結構
lualib.h:
和Lua一樣，標準庫的API
luajit.h:
luajit 的public API
vm_*.dasc:
編譯期被DynASM預處理的源文件，下一篇講DynASM時候介紹dasc文件
wmain.c:
windows下面的main入口
和Trace相關的：
lj_crecord.h/.c ： C操作的trace record
lj_dispatch.h/.c : 指令分發，調用ASMFuction，處理指令前的hook和記錄trace用的hot count，有一個重要的數據結構 GG_State
lj_ff*.h/.c: 上面講lj_ffdef.h的時候提過，trace的時候 記錄Fast Function的調用記數
lj_trace.h/.c: trace的具體過程
lj_traceerr.h : trace error