Difference between revisions of "LuaC"
m (expanded "spec" to "specification") |
m (...and again.) |
||
| Line 9: | Line 9: | ||
Sounds useful? Keep reading. | Sounds useful? Keep reading. | ||
| − | Lua byte-codes are not part of the Lua specification but rather a practical result of the LuaVM's design. The LuaVM is also not a part of any standardized | + | Lua byte-codes are not part of the Lua specification but rather a practical result of the LuaVM's design. The LuaVM is also not a part of any standardized specification, for it too is an implementation detail. |
'''The only part of Lua that has a standardized specification is the language itself, and the CAPI.''' '''''Nothing else.''''' | '''The only part of Lua that has a standardized specification is the language itself, and the CAPI.''' '''''Nothing else.''''' | ||
| − | The incompatibility of the byte-codes stems from this. Since there is no | + | The incompatibility of the byte-codes stems from this. Since there is no specification for Lua byte-codes, and '''they are not meant to be ported between different builds of Lua''', there's no need to insulate the byte-codes from the vagaries and tribulations of the compiler. The upshot of this is that the compiler is free to rearrange the various <tt>struct</tt>s and <tt>enum</tt>s upon which the VM relies as deems fit (usually for efficiency), the down side is that '''any byte-code is potentially idiosyncratic to the exact build of lua that created it.''' |
''"But then, why create LuaC?"'', a question with a simple answer: One possible build configuration of Lua is parserless (an ultra-small size Lua build), which has the down side that it is unable to process source files on its own; it must be given pre-parsed source files...which is to say, byte-codes. | ''"But then, why create LuaC?"'', a question with a simple answer: One possible build configuration of Lua is parserless (an ultra-small size Lua build), which has the down side that it is unable to process source files on its own; it must be given pre-parsed source files...which is to say, byte-codes. | ||
Revision as of 11:56, 29 September 2010
|
We're not kidding here; LuaC might have its uses, but it comes with a lot of strings attached.
|
LuaC is tool which takes a lua source file and parses it into lua byte-code.
Sounds useful? Keep reading.
Lua byte-codes are not part of the Lua specification but rather a practical result of the LuaVM's design. The LuaVM is also not a part of any standardized specification, for it too is an implementation detail. The only part of Lua that has a standardized specification is the language itself, and the CAPI. Nothing else.
The incompatibility of the byte-codes stems from this. Since there is no specification for Lua byte-codes, and they are not meant to be ported between different builds of Lua, there's no need to insulate the byte-codes from the vagaries and tribulations of the compiler. The upshot of this is that the compiler is free to rearrange the various structs and enums upon which the VM relies as deems fit (usually for efficiency), the down side is that any byte-code is potentially idiosyncratic to the exact build of lua that created it.
"But then, why create LuaC?", a question with a simple answer: One possible build configuration of Lua is parserless (an ultra-small size Lua build), which has the down side that it is unable to process source files on its own; it must be given pre-parsed source files...which is to say, byte-codes. The same limitations apply, though; the build of LuaC used must match the VM. A brittle solution, but tolerable given the circumstances.
