根据源码梳理LuaJIT解释器模式（一）

LuaJIT有两种执行模式&＃xff0c;解释模式和即时编译&＃xff08;JIT&＃xff09;模式。这里暂且抛开JIT模式&＃xff0c;主要介绍解释器模式的技术实现。解释器模式的主要模块关系如下图所示&＃xff1a;

解释器模式基本上可以分为两个阶段&＃xff1a;第一个阶段词法分析器提取分析Lua source字符流构成token&＃xff08;这一过程在src/lj_lex.c中&＃xff09;&＃xff0c;语法分析器再使用token流进行语法分析、语义分析&＃xff0c;最后生成可供LuaJIT虚拟机识别的Bytecode中间码&＃xff08;src/lj_parse.c&＃xff09;。第二个阶段解释器对Bytecode一条条的按字节码逻辑进行解析执行&＃xff08;src/vm_loongarch64.dasc&＃xff09;。根据对源码的梳理&＃xff0c;做出以下时序图&＃xff1a;

LuaJIT开始于main函数&＃xff0c;在main中调用lua_open()创建虚拟机&＃xff08;VM&＃xff09;&＃xff0c;然后在lua_cpcall中调用lj_vm_cpcall(L, func, ud, cpcall)函数进入VM&＃xff0c;该函数对应这汇编代码中的vm_cpcall。参数func是函数pmain的指针&＃xff0c;加载source文件至VM解释执行就是其发起的&＃xff0c;参数cpcall是函数cacall的指针&＃xff0c;cpcall函数主要为执行pmain做了一个准备工作。

在pmain中&＃xff0c;首先检查执行命令中的参数&＃xff0c;根据参数做相应动作&＃xff0c;如./luajit -v&＃xff0c;会输出luajit的版本信息。luaL_openlibs(L)会打开所有的Lua标准库&＃xff0c;调用handle_script发起加载source文件解释执行。

在lua_loadx中&＃xff0c;再次通过lj_vm_cpcall执行函数cpparser&＃xff0c;cpparser则是真正的开始为source code -> bytecode这一过程做准备。这里有三个类型需注意&＃xff1a;

• LexState是词法解析的上下文&＃xff0c;通过该类型的对象可以获取所有词法相关的信息&＃xff0c;包括Current token及其位置、token value、Current character等&＃xff1b;
• GCproto是函数的原型&＃xff0c;存放函数paser完生成的bytecode和中间结构的信息&＃xff0c;包括常量数组、bytecode指令等&＃xff1b;
• GCfunc是union&＃xff0c;封装了Lua函数和C函数&＃xff0c;也就是一个该类型的对象只能表示为一个Lua函数或一个C函数。

区分GCproto&＃xff08;原型&＃xff09;和GCfunc&＃xff08;函数&＃xff09;的区别&＃xff0c;GCproto中存放的是函数生成的bytecode指令集及其相关的中间结构信息&＃xff0c;会以此去创建闭包&＃xff0c;将创建的闭包信息存放到GCfunc中&＃xff0c;从而让VM执行Lua或C函数。bc ? lj_bcread(ls) : lj_parse(ls)根据bc的值选择是parse Lua source还是直接执行bytecode&＃xff0c;bc的值根据脚本文件中的前几个字符确定。

lj_parse进入parse阶段&＃xff0c;在parse时会创建FuncState对象。FuncState是当前正在parse的函数上下文信息&＃xff0c;如*prev指向父函数或者外部函数&＃xff0c;nactvar表示当前局部变量在stack上的位置&＃xff0c;freereg表示第一个可用的stack slot&＃xff0c;vbase是当前函数stack的base等。首先bcemit_AD(&fs, BC_FUNCV, 0, 0)生成一条BC_FUNCV指令&＃xff0c;这条指令并不是最终的指令&＃xff0c;如果是JIT模式&＃xff0c;后面会被BC_IFUNCV执行替换。从这里已经可以看出来&＃xff0c;从source->bytecode这一过程是直译的&＃xff0c;没有生成AST或其他中间码。

parse_chunk被用于block级别的parse&＃xff0c;这个block可以是函数或者复合语句&＃xff08;if、for等&＃xff09;的block&＃xff0c;如&＃xff1a;

function fname() block
endif cond then block
end


从parse_chunk中循环调用parse_stmt做语句级别的parse&＃xff0c;直到遇到return语句或者标志某条复合语句block结束的token后&＃xff08;如else、elseif和end标志着if then后面的block结束&＃xff09;结束。

parse完成后&＃xff0c;会执行fs_finish函数&＃xff0c;将parse阶段生成的Bytecode和中间结构&＃xff0c;以及收集到的函数context信息重新组织为一个新的数组结构&＃xff0c;放到紧跟在GCproto之后的位置&＃xff0c;并将这些数组结构的基地址和size存放到GCproto或lua_State对象中&＃xff0c;供VM解释器做解释计算时使用。下图为重新组织的数组结构图&＃xff0c;其中pt为GCproto&＃xff0c;fs为FuncState&＃xff1a;

至此parse过程已经完成&＃xff0c;如果source没有错误&＃xff0c;会返回GCproto*。执行函数lj_func_newL_empty(L, pt, tabref(L->env))创建一个GCfunc&＃xff0c;并将其存放到Stack的第一个free slot上&＃xff08;L->top所指位置&＃xff09;&＃xff0c;供VM解释器执行使用。待cpparser函数执行完&＃xff0c;PC&＃xff08;程序计数器&＃xff0c;别跟VM的PC混淆&＃xff09;返回到VM的函数vm_cpcall的or BASE, CRET1, r0指令&＃xff0c;此时寄存器CRET1的值为0&＃xff0c;vm_cpcall会返回到进入它的C函数lua_loadx&＃xff0c;再lua_loadx由一直返回到handle_script函数中。返回值status为0&＃xff08;LUA_OK &＃61; 0&＃xff09;&＃xff0c;所以会按照执行路径docall(L, narg, 0)、lua_pcall(L, narg, (clear ? 0 : LUA_MULTRET), base)、lj_vm_pcall(L, api_call_base(L, nargs), nresults&＃43;1, ef)进入VM开始对生成的Bytecode解释执行。

首先执行vm_pcall&＃xff0c;其中参数 TValue *base 指针指向VM Stack的base地址&＃xff0c;L->top指向VM Stack的第一个free slot&＃xff0c;所以即将要执行的函数的参数个数可通过L->top - base获得。该函数的主要作用是将进入VM之前的C函数的保存寄存器&＃xff08;callee寄存器&＃xff09;的值保存在运行时栈上&＃xff0c;等VM执行结束返回时再取出恢复C的运行环境。

接着执行vm_call&＃xff0c;这部分主要准备VM函数的运行环境&＃xff0c;如为寄存器BASE、PC、DISPATCH赋相应的值&＃xff0c;当前要运行的Lua函数的闭包存放在FRAME_FUNC(BASE)中&＃xff0c;这里将其存放在了寄存器RB中&＃xff0c;在ins_call中会使用&＃xff0c;跳到要执行的函数Bytecode相关指令对应的函数中执行。具体如何执行&＃xff0c;会在根据源码梳理LuaJIT解释器模式&＃xff08;二&＃xff09; 中详细介绍。

待Bytecodeui对应的函数执行完之后&＃xff0c;会Return handling相关的函数回到C函数中&＃xff0c;最终回到main中。返回到C函数中后&＃xff0c;VM Stack的结构如下&＃xff1a;

----------------------------
| ret1 | ... | retn | |
----------------------------base n-1 L->top