As a broad overview, the Lua core operates by first compiling source text to an intermediate form called bytecode, which is then executed by an interpreter. Compilation to bytecode improves performance partly by performing the expensive lexical and syntax analysis once only, and partly by providing opportunities for optimizations that would be extremely difficult to perform without a compilation phase. The bytecode is the machine language of a register virtual machine. It has been designed to correspond well to the semantics of Lua, and to be easily interpreted.
The standalone executable simply loads the Lua core, acts on any options (such as -l
and -e
) that take effect ahead of a named script, compiles, loads, and executes the named script, and returns status to the OS in the usual way.
So that errors are handled consistently, one confusion in the lua.c
is the delegation of all actual work aside from creation of the Lua state to the function pmain
instead of just doing it in main
. This allows pmain
to be called in a protected context so that errors it throws will be caught rather than causing the abnormal termination of main
.
While the source to the core of Lua is obscure, it is remarkably well documented. It does require a fair bit of background in compiler design, language design, virtual machines, and related topics to really understand it in depth.
There have been numerous academic papers about the language, its implementation, and its application. Those will provide a goldmine of information about why certain decisions were made, and in some cases, later revised.
The Lua User's Wiki has some pages devoted to exploration of the internal mechanisms of several features of the language, as well as lots of content about its use and extension.
Finally, I'll mention that the source code to the standard library modules is much more accessible that the source to the core. It will always provide solid examples of techniques for interfacing an external library to Lua.