Notes on Lua code

Function prefixes, header files

Internal function prefixes and header files
Prefix	Header	Abstraction
`luaL_`	`lauxlib.h`	Auxiliary library (extends public API)
`luaK_`	`lcode.h`	Code generator
N/A	`lctype.h`	Replacement for `ctype.h`
`luaG_`	`ldebug.h`	Debug hooks?
`luaD_`	`ldo.h`	Calls; register-window stack
`luaF_`	`lfunc.h`	Closures and free varibles (“upvalues”)
`luaC_`	`lgc.h`	Garbage collection
`luaX_`	`llex.h`	Lexical analysis
N/A	`llimits.h`	Sizes, limits, numeric-operation macros
`luaM_`	`lmem.h`	Allocation
`luaO_`	`lobject.h`	Key representations: Values, type tags, conversions
N/A	`lopcodes.h`	Instruction decoding; opcode table
N/A	`lparser.h`	Parser; classification of names
`luaE_`	`lstate.h`	Interpreter state; call stack
`luaS_`	`lstring.h`	Strings
`luaH_`	`ltable.h`	(Hash) tables
`luaT_`	`ltm.h`	Tag methods (metamethods)
`lua_`	`lua.h`	Public (C) API
N/A	`luaconf.h`	Configuration for portability (uninteresting)
`luaopen_`	`lualib.h`	Access to standard libraries
`luaV_`	`lvm.h`	Bytecode interpreter & operations
`luaZ_`	`lzio.h`	Buffered streams

Note how every instruction dispatch is protected by assertions about the stack. And how the PC does not live in a register.

Note Protect macro which makes code resilient against reallocation of the stack.

Structure CallInfo might be an activation record.

Label newframe enables Lua call/return without C call/return.

Critical parts of the VM state:

How does luaD_precall work? Does it set L->ci to the new activation record?

Tail call to a C function appears to be the same as a non-tail call to a C function.

Questions: