| blob | 51d02fca89f2460cf2b73ecdd962b423c05ebdee |
2 <html>
3 <head>
14 }
17 }
20 }
23 }
26 }
27 </style>
28 </head>
29 <body>
32 </div>
35 </div>
37 <ul><li>
39 <ul><li>
41 </li><li>
43 </li><li>
45 </li></ul>
46 </li><li>
48 <ul><li>
50 <ul><li>
52 </li><li>
54 </li><li>
56 </li></ul>
57 </li><li>
59 </li><li>
61 </li><li>
63 </li></ul>
64 </li><li>
66 <ul><li>
68 </li></ul>
69 </li><li>
71 </li><li>
73 </li><li>
75 </li><li>
77 </li></ul>
78 </div>
80 <p>
81 LuaJIT is fully upwards-compatible with Lua 5.1. It supports all
82 <a href="http://www.lua.org/manual/5.1/manual.html#5"><span class="ext">»</span> standard Lua
83 library functions</a> and the full set of
84 <a href="http://www.lua.org/manual/5.1/manual.html#3"><span class="ext">»</span> Lua/C API
85 functions</a>.
86 </p>
87 <p>
88 LuaJIT is also fully ABI-compatible to Lua 5.1 at the linker/dynamic
89 loader level. This means you can compile a C module against the
90 standard Lua headers and load the same shared library from either Lua
91 or LuaJIT.
92 </p>
93 <p>
94 LuaJIT extends the standard Lua VM with new functionality and adds
95 several extension modules. Please note this page is only about
97 such as the optimized VM, the faster interpreter or the JIT compiler.
98 </p>
101 <p>
102 LuaJIT comes with several built-in extension modules:
103 </p>
106 <p>
107 LuaJIT supports all bitwise operations as defined by
109 </p>
111 bit.tobit bit.tohex bit.bnot bit.band bit.bor bit.bxor
112 bit.lshift bit.rshift bit.arshift bit.rol bit.ror bit.bswap
113 </pre>
114 <p>
115 This module is a LuaJIT built-in — you don't need to download or
116 install Lua BitOp. The Lua BitOp site has full documentation for all
117 <a href="http://bitop.luajit.org/api.html"><span class="ext">»</span> Lua BitOp API functions</a>.
118 The FFI adds support for
120 using the same API functions.
121 </p>
122 <p>
124 its functions:
125 </p>
127 local bit = require("bit")
128 </pre>
129 <p>
130 An already installed Lua BitOp module is ignored by LuaJIT.
131 This way you can use bit operations from both Lua and LuaJIT on a
132 shared installation.
133 </p>
136 <p>
139 code.
140 </p>
143 <p>
144 The functions in this module
146 </p>
149 <p>
150 LuaJIT adds some
152 </p>
155 <p>
157 </p>
162 <p>
164 passes any arguments after the error function to the function
165 which is called in a protected context.
166 </p>
169 <p>
170 Non-ASCII characters are handled transparently by the Lua source code parser.
171 This allows the use of UTF-8 characters in identifiers and strings.
172 A UTF-8 BOM is skipped at the start of the source code.
173 </p>
176 <p>
177 All number-to-string conversions consistently convert non-finite numbers
181 </p>
184 <p>
185 All string-to-number conversions consistently convert integer and
186 floating-point inputs in decimal, hexadecimal and binary on all platforms.
188 problems with poor C library implementations. The builtin conversion
189 function provides full precision according to the IEEE-754 standard, it
190 works independently of the current locale and it supports hex floating-point
192 </p>
195 <p>
198 generated. This speeds up later bytecode loading and reduces memory
199 usage. See also the
201 </p>
202 <p>
203 The generated bytecode is portable and can be loaded on any architecture
204 that LuaJIT supports, independent of word size or endianess. However the
205 bytecode compatibility versions must match. Bytecode stays compatible
208 bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded.
209 </p>
210 <p>
212 a different, incompatible bytecode format for ports that use this mode (e.g.
213 ARM64). This may be rectified in the future.
214 </p>
217 <p>
221 tables if the final table size is known and automatic table resizing is
222 too expensive.
223 </p>
226 <p>
229 from a table, but preserves the allocated array/hash sizes. This is
230 useful when a table, which is linked from multiple places, needs to be
231 cleared and/or when recycling a table for use by the same context. This
232 avoids managing backlinks, saves an allocation and the overhead of
233 incremental array/hash part growth.
234 </p>
235 <p>
236 Please note this function is meant for very specific situations. In most
237 cases it's better to replace the (usually single) link with a new table
238 and let the GC do its work.
239 </p>
242 <p>
245 the PRNG results is much superior compared to the standard Lua
246 implementation which uses the platform-specific ANSI rand().
247 </p>
248 <p>
249 The PRNG generates the same sequences from the same seeds on all
250 platforms and makes use of all bits in the seed argument.
254 preserve uniformity.
255 </p>
258 <p>
264 </p>
267 <p>
272 </p>
275 <p>
276 The LuaJIT VM is fully resumable. This means you can yield from a
277 coroutine even across contexts, where this would not possible with
280 </p>
283 <p>
285 Features that are unlikely to break existing code are unconditionally
286 enabled:
287 </p>
288 <ul>
299 <li>String matching pattern <tt>%g</tt> added.</li>
301 <li><tt>io.lines()</tt> and <tt>file:lines()</tt> process
302 <tt>io.read()</tt> options.</li>
303 <li><tt>os.exit(status|true|false [,close])</tt>.</li>
304 <li><tt>package.searchpath(name, path [, sep [, rep]])</tt>.</li>
306 <li><tt>debug.getinfo()</tt> returns <tt>nparams</tt> and <tt>isvararg</tt>
308 <li><tt>debug.getlocal()</tt> accepts function instead of level.</li>
309 <li><tt>debug.getlocal()</tt> and <tt>debug.setlocal()</tt> accept negative
310 indexes for varargs.</li>
311 <li><tt>debug.getupvalue()</tt> and <tt>debug.setupvalue()</tt> handle
312 C functions.</li>
313 <li><tt>debug.upvalueid()</tt> and <tt>debug.upvaluejoin()</tt>.</li>
314 <li>Command line option <tt>-E</tt>.</li>
315 <li>Command line checks <tt>__tostring</tt> for errors.</li>
316 </ul>
317 <p>
318 Other features are only enabled, if LuaJIT is built with
319 <tt>-DLUAJIT_ENABLE_LUA52COMPAT</tt>:
320 </p>
321 <ul>
322 <li><tt>goto</tt> is a keyword and not a valid variable name anymore.</li>
323 <li><tt>break</tt> can be placed anywhere. Empty statements (<tt>;;</tt>)
324 are allowed.</li>
325 <li><tt>__lt</tt>, <tt>__le</tt> are invoked for mixed types.</li>
326 <li><tt>__len</tt> for tables. <tt>rawlen()</tt> library function.</li>
327 <li><tt>pairs()</tt> and <tt>ipairs()</tt> check for <tt>__pairs</tt> and
328 <tt>__ipairs</tt>.</li>
329 <li><tt>coroutine.running()</tt> returns two results.</li>
330 <li><tt>table.pack()</tt> and <tt>table.unpack()</tt>
331 (same as <tt>unpack()</tt>).</li>
332 <li><tt>io.write()</tt> and <tt>file:write()</tt> return file handle
333 instead of <tt>true</tt>.</li>
334 <li><tt>os.execute()</tt> and <tt>pipe:close()</tt> return detailed
335 exit status.</li>
336 <li><tt>debug.setmetatable()</tt> returns object.</li>
337 <li><tt>debug.getuservalue()</tt> and <tt>debug.setuservalue()</tt>.</li>
338 <li>Remove <tt>math.mod()</tt>, <tt>string.gfind()</tt>.
339 </ul>
340 <p>
341 Note: this provides only partial compatibility with Lua 5.2 at the
342 language and Lua library level. LuaJIT is API+ABI-compatible with
343 Lua 5.1, which prevents implementing features that would otherwise
344 break the Lua/C API and ABI (e.g. <tt>_ENV</tt>).
345 </p>
348 <p>
349 LuaJIT has built-in support for interoperating with C++ exceptions.
350 The available range of features depends on the target platform and
351 the toolchain used to compile LuaJIT:
352 </p>
358 </tr>
363 </tr>
368 </tr>
373 </tr>
378 </tr>
383 </tr>
384 </table>
385 <p>
387 </p>
388 <ul>
389 <li>C++ exceptions can be caught on the Lua side with <tt>pcall()</tt>,
390 <tt>lua_pcall()</tt> etc.</li>
391 <li>C++ exceptions will be converted to the generic Lua error
394 <li>It's safe to throw C++ exceptions across non-protected Lua frames
395 on the C stack. The contents of the C++ exception object
396 pass through unmodified.</li>
397 <li>Lua errors can be caught on the C++ side with <tt>catch(...)</tt>.
398 The corresponding Lua error message can be retrieved from the Lua stack.</li>
399 <li>Throwing Lua errors across C++ frames is safe. C++ destructors
400 will be called.</li>
401 </ul>
402 <p>
404 </p>
405 <ul>
406 <li>C++ exceptions can be caught on the Lua side with <tt>pcall()</tt>,
407 <tt>lua_pcall()</tt> etc.</li>
408 <li>C++ exceptions will be converted to the generic Lua error
411 <li>C++ exceptions will be caught by non-protected Lua frames and
412 are rethrown as a generic Lua error. The C++ exception object will
413 be destroyed.</li>
414 <li>Lua errors <b>cannot</b> be caught on the C++ side.</li>
415 <li>Throwing Lua errors across C++ frames will <b>not</b> call
416 C++ destructors.</li>
417 </ul>
419 <p>
421 </p>
422 <ul>
423 <li>It's <b>not</b> safe to throw C++ exceptions across Lua frames.</li>
424 <li>C++ exceptions <b>cannot</b> be caught on the Lua side.</li>
425 <li>Lua errors <b>cannot</b> be caught on the C++ side.</li>
426 <li>Throwing Lua errors across C++ frames will <b>not</b> call
427 C++ destructors.</li>
428 <li>Additionally, on Windows/x86 with SEH-based C++ exceptions:
429 it's <b>not</b> safe to throw a Lua error across any frames containing
430 a C++ function with any try/catch construct or using variables with
431 (implicit) destructors. This also applies to any functions which may be
432 inlined in such a function. It doesn't matter whether <tt>lua_error()</tt>
433 is called inside or outside of a try/catch or whether any object actually
434 needs to be destroyed: the SEH chain is corrupted and this will eventually
435 lead to the termination of the process.</li>
436 </ul>
438 </div>
441 Copyright © 2005-2015 Mike Pall
443 ·
445 </span>
446 </div>
447 </body>
448 </html>