mirror of
https://github.com/LuaJIT/LuaJIT.git
synced 2025-02-07 15:14:08 +00:00
Grammar and spell check.
This commit is contained in:
parent
7dc3850e78
commit
2e98c3d064
@ -103,7 +103,7 @@ Turn the whole JIT compiler on or off or flush the whole cache of compiled code.
|
|||||||
This sets the mode for the function at the stack index <tt>idx</tt> or
|
This sets the mode for the function at the stack index <tt>idx</tt> or
|
||||||
the parent of the calling function (<tt>idx = 0</tt>). It either
|
the parent of the calling function (<tt>idx = 0</tt>). It either
|
||||||
enables JIT compilation for a function, disables it and flushes any
|
enables JIT compilation for a function, disables it and flushes any
|
||||||
already compiled code or only flushes already compiled code. This
|
already compiled code, or only flushes already compiled code. This
|
||||||
applies recursively to all sub-functions of the function with
|
applies recursively to all sub-functions of the function with
|
||||||
<tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with
|
<tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with
|
||||||
<tt>LUAJIT_MODE_ALLSUBFUNC</tt>.
|
<tt>LUAJIT_MODE_ALLSUBFUNC</tt>.
|
||||||
@ -122,7 +122,7 @@ traces which link to it.
|
|||||||
This mode defines a wrapper function for calls to C functions. If
|
This mode defines a wrapper function for calls to C functions. If
|
||||||
called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt>
|
called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt>
|
||||||
must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper
|
must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper
|
||||||
function. From now on all C functions are called through the wrapper
|
function. From now on, all C functions are called through the wrapper
|
||||||
function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned
|
function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned
|
||||||
off and all C functions are directly called.
|
off and all C functions are directly called.
|
||||||
</p>
|
</p>
|
||||||
|
@ -153,7 +153,7 @@ call the binding function. Phew!
|
|||||||
<h2 id="cdata">Motivating Example: Using C Data Structures</h2>
|
<h2 id="cdata">Motivating Example: Using C Data Structures</h2>
|
||||||
<p>
|
<p>
|
||||||
The FFI library allows you to create and access C data
|
The FFI library allows you to create and access C data
|
||||||
structures. Of course the main use for this is for interfacing with
|
structures. Of course, the main use for this is for interfacing with
|
||||||
C functions. But they can be used stand-alone, too.
|
C functions. But they can be used stand-alone, too.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
@ -165,7 +165,7 @@ implemented with a big table holding lots of tiny tables. This imposes
|
|||||||
both a substantial memory overhead as well as a performance overhead.
|
both a substantial memory overhead as well as a performance overhead.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Here's a sketch of a library that operates on color images plus a
|
Here's a sketch of a library that operates on color images, plus a
|
||||||
simple benchmark. First, the plain Lua version:
|
simple benchmark. First, the plain Lua version:
|
||||||
</p>
|
</p>
|
||||||
<pre class="code">
|
<pre class="code">
|
||||||
@ -180,7 +180,7 @@ local function image_ramp_green(n)
|
|||||||
return img
|
return img
|
||||||
end
|
end
|
||||||
|
|
||||||
local function image_to_grey(img, n)
|
local function image_to_gray(img, n)
|
||||||
for i=1,n do
|
for i=1,n do
|
||||||
local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue)
|
local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue)
|
||||||
img[i].red = y; img[i].green = y; img[i].blue = y
|
img[i].red = y; img[i].green = y; img[i].blue = y
|
||||||
@ -190,14 +190,14 @@ end
|
|||||||
local N = 400*400
|
local N = 400*400
|
||||||
local img = image_ramp_green(N)
|
local img = image_ramp_green(N)
|
||||||
for i=1,1000 do
|
for i=1,1000 do
|
||||||
image_to_grey(img, N)
|
image_to_gray(img, N)
|
||||||
end
|
end
|
||||||
</pre>
|
</pre>
|
||||||
<p>
|
<p>
|
||||||
This creates a table with 160.000 pixels, each of which is a table
|
This creates a table with 160.000 pixels, each of which is a table
|
||||||
holding four number values in the range of 0-255. First an image with
|
holding four number values in the range of 0-255. First, an image with
|
||||||
a green ramp is created (1D for simplicity), then the image is
|
a green ramp is created (1D for simplicity), then the image is
|
||||||
converted to greyscale 1000 times. Yes, that's silly, but I was in
|
converted to grayscale 1000 times. Yes, that's silly, but I was in
|
||||||
need of a simple example ...
|
need of a simple example ...
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
@ -304,7 +304,7 @@ be more compact and faster. This is certainly true (by a factor of
|
|||||||
~1.7x). Switching to a struct-of-arrays would help, too.
|
~1.7x). Switching to a struct-of-arrays would help, too.
|
||||||
</p>
|
</p>
|
||||||
<p style="font-size: 8pt;">
|
<p style="font-size: 8pt;">
|
||||||
However the resulting code would be less idiomatic and rather
|
However, the resulting code would be less idiomatic and rather
|
||||||
error-prone. And it still doesn't get even close to the performance of
|
error-prone. And it still doesn't get even close to the performance of
|
||||||
the FFI version of the code. Also, high-level data structures cannot
|
the FFI version of the code. Also, high-level data structures cannot
|
||||||
be easily passed to other C functions, especially I/O functions,
|
be easily passed to other C functions, especially I/O functions,
|
||||||
|
@ -117,7 +117,7 @@ separated by semicolons. The trailing semicolon for a single
|
|||||||
declaration may be omitted.
|
declaration may be omitted.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Please note that external symbols are only <em>declared</em>, but they
|
Please note, that external symbols are only <em>declared</em>, but they
|
||||||
are <em>not bound</em> to any specific address, yet. Binding is
|
are <em>not bound</em> to any specific address, yet. Binding is
|
||||||
achieved with C library namespaces (see below).
|
achieved with C library namespaces (see below).
|
||||||
</p>
|
</p>
|
||||||
@ -205,7 +205,7 @@ parse the cdecl only once and get its ctype with
|
|||||||
<tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly.
|
<tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly.
|
||||||
</p>
|
</p>
|
||||||
<p style="font-size: 8pt;">
|
<p style="font-size: 8pt;">
|
||||||
Please note that an anonymous <tt>struct</tt> declaration implicitly
|
Please note, that an anonymous <tt>struct</tt> declaration implicitly
|
||||||
creates a new and distinguished ctype every time you use it for
|
creates a new and distinguished ctype every time you use it for
|
||||||
<tt>ffi.new()</tt>. This is probably <b>not</b> what you want,
|
<tt>ffi.new()</tt>. This is probably <b>not</b> what you want,
|
||||||
especially if you create more than one cdata object. Different anonymous
|
especially if you create more than one cdata object. Different anonymous
|
||||||
@ -252,12 +252,12 @@ afterwards. Neither the contents of the <tt>metatable</tt> nor the
|
|||||||
contents of an <tt>__index</tt> table (if any) may be modified
|
contents of an <tt>__index</tt> table (if any) may be modified
|
||||||
afterwards. The associated metatable automatically applies to all uses
|
afterwards. The associated metatable automatically applies to all uses
|
||||||
of this type, no matter how the objects are created or where they
|
of this type, no matter how the objects are created or where they
|
||||||
originate from. Note that pre-defined operations on types have
|
originate from. Note that predefined operations on types have
|
||||||
precedence (e.g. declared field names cannot be overridden).
|
precedence (e.g. declared field names cannot be overridden).
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
All standard Lua metamethods are implemented. These are called directly,
|
All standard Lua metamethods are implemented. These are called directly,
|
||||||
without shortcuts and on any mix of types. For binary operations, the
|
without shortcuts, and on any mix of types. For binary operations, the
|
||||||
left operand is checked first for a valid ctype metamethod. The
|
left operand is checked first for a valid ctype metamethod. The
|
||||||
<tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt>
|
<tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt>
|
||||||
types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a>
|
types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a>
|
||||||
@ -484,7 +484,7 @@ have some extra methods:
|
|||||||
<p>
|
<p>
|
||||||
Free the resources associated with a callback. The associated Lua
|
Free the resources associated with a callback. The associated Lua
|
||||||
function is unanchored and may be garbage collected. The callback
|
function is unanchored and may be garbage collected. The callback
|
||||||
function pointer is no longer valid and must not be called anymore
|
function pointer is no longer valid and must not be called again
|
||||||
(it may be reused by a subsequently created callback).
|
(it may be reused by a subsequently created callback).
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
@ -84,7 +84,7 @@ footprint. It's used by the <a href="ext_ffi_api.html">ffi.* library
|
|||||||
functions</a> to declare C types or external symbols.
|
functions</a> to declare C types or external symbols.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
It's only purpose is to parse C declarations, as found e.g. in
|
Its only purpose is to parse C declarations, as found e.g. in
|
||||||
C header files. Although it does evaluate constant expressions,
|
C header files. Although it does evaluate constant expressions,
|
||||||
it's <em>not</em> a C compiler. The body of <tt>inline</tt>
|
it's <em>not</em> a C compiler. The body of <tt>inline</tt>
|
||||||
C function definitions is simply ignored.
|
C function definitions is simply ignored.
|
||||||
@ -161,7 +161,7 @@ function declarations.</li>
|
|||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
The following C types are pre-defined by the C parser (like
|
The following C types are predefined by the C parser (like
|
||||||
a <tt>typedef</tt>, except re-declarations will be ignored):
|
a <tt>typedef</tt>, except re-declarations will be ignored):
|
||||||
</p>
|
</p>
|
||||||
<ul>
|
<ul>
|
||||||
@ -577,9 +577,9 @@ ffi.new("struct nested", {x=1,y={2,3}}) --> x = 1, y.a = 2, y.b = 3
|
|||||||
|
|
||||||
<h2 id="cdata_ops">Operations on cdata Objects</h2>
|
<h2 id="cdata_ops">Operations on cdata Objects</h2>
|
||||||
<p>
|
<p>
|
||||||
All of the standard Lua operators can be applied to cdata objects or a
|
All standard Lua operators can be applied to cdata objects or a
|
||||||
mix of a cdata object and another Lua object. The following list shows
|
mix of a cdata object and another Lua object. The following list shows
|
||||||
the pre-defined operations.
|
the predefined operations.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Reference types are dereferenced <em>before</em> performing each of
|
Reference types are dereferenced <em>before</em> performing each of
|
||||||
@ -587,7 +587,7 @@ the operations below — the operation is applied to the
|
|||||||
C type pointed to by the reference.
|
C type pointed to by the reference.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The pre-defined operations are always tried first before deferring to a
|
The predefined operations are always tried first before deferring to a
|
||||||
metamethod or index table (if any) for the corresponding ctype (except
|
metamethod or index table (if any) for the corresponding ctype (except
|
||||||
for <tt>__new</tt>). An error is raised if the metamethod lookup or
|
for <tt>__new</tt>). An error is raised if the metamethod lookup or
|
||||||
index table lookup fails.
|
index table lookup fails.
|
||||||
@ -637,7 +637,7 @@ assigning to an index of a vector raises an error.</li>
|
|||||||
</ul>
|
</ul>
|
||||||
<p>
|
<p>
|
||||||
A ctype object can be indexed with a string key, too. The only
|
A ctype object can be indexed with a string key, too. The only
|
||||||
pre-defined operation is reading scoped constants of
|
predefined operation is reading scoped constants of
|
||||||
<tt>struct</tt>/<tt>union</tt> types. All other accesses defer
|
<tt>struct</tt>/<tt>union</tt> types. All other accesses defer
|
||||||
to the corresponding metamethods or index tables (if any).
|
to the corresponding metamethods or index tables (if any).
|
||||||
</p>
|
</p>
|
||||||
@ -650,7 +650,7 @@ certain optimizations.
|
|||||||
<p>
|
<p>
|
||||||
As a consequence, the <em>elements</em> of complex numbers and
|
As a consequence, the <em>elements</em> of complex numbers and
|
||||||
vectors are immutable. But the elements of an aggregate holding these
|
vectors are immutable. But the elements of an aggregate holding these
|
||||||
types <em>may</em> be modified of course. I.e. you cannot assign to
|
types <em>may</em> be modified, of course. I.e. you cannot assign to
|
||||||
<tt>foo.c.im</tt>, but you can assign a (newly created) complex number
|
<tt>foo.c.im</tt>, but you can assign a (newly created) complex number
|
||||||
to <tt>foo.c</tt>.
|
to <tt>foo.c</tt>.
|
||||||
</p>
|
</p>
|
||||||
@ -669,8 +669,8 @@ through unions is explicitly detected and allowed.
|
|||||||
to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is
|
to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is
|
||||||
defined. The <tt>__new</tt> metamethod is called with the ctype object
|
defined. The <tt>__new</tt> metamethod is called with the ctype object
|
||||||
plus any other arguments passed to the constructor. Note that you have to
|
plus any other arguments passed to the constructor. Note that you have to
|
||||||
use <tt>ffi.new</tt> inside of it, since calling <tt>ct(...)</tt> would
|
use <tt>ffi.new</tt> inside the metamethod, since calling <tt>ct(...)</tt>
|
||||||
cause infinite recursion.</li>
|
would cause infinite recursion.</li>
|
||||||
|
|
||||||
<li><b>C function call</b>: a cdata function or cdata function
|
<li><b>C function call</b>: a cdata function or cdata function
|
||||||
pointer can be called. The passed arguments are
|
pointer can be called. The passed arguments are
|
||||||
@ -681,7 +681,7 @@ variable argument part of vararg C function use
|
|||||||
C function is called and the return value (if any) is
|
C function is called and the return value (if any) is
|
||||||
<a href="#convert_tolua">converted to a Lua object</a>.<br>
|
<a href="#convert_tolua">converted to a Lua object</a>.<br>
|
||||||
On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically
|
On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically
|
||||||
detected and a function declared as <tt>__cdecl</tt> (the default) is
|
detected, and a function declared as <tt>__cdecl</tt> (the default) is
|
||||||
silently fixed up after the first call.</li>
|
silently fixed up after the first call.</li>
|
||||||
|
|
||||||
</ul>
|
</ul>
|
||||||
@ -691,7 +691,7 @@ silently fixed up after the first call.</li>
|
|||||||
|
|
||||||
<li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata
|
<li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata
|
||||||
number or a Lua number can be added or subtracted. The number must be
|
number or a Lua number can be added or subtracted. The number must be
|
||||||
on the right hand side for a subtraction. The result is a pointer of
|
on the right-hand side for a subtraction. The result is a pointer of
|
||||||
the same type with an address plus or minus the number value
|
the same type with an address plus or minus the number value
|
||||||
multiplied by the element size in bytes. An error is raised if the
|
multiplied by the element size in bytes. An error is raised if the
|
||||||
element size is undefined.</li>
|
element size is undefined.</li>
|
||||||
@ -706,7 +706,7 @@ operators (<tt>+ - * / % ^</tt> and unary
|
|||||||
minus) can be applied to two cdata numbers, or a cdata number and a
|
minus) can be applied to two cdata numbers, or a cdata number and a
|
||||||
Lua number. If one of them is an <tt>uint64_t</tt>, the other side is
|
Lua number. If one of them is an <tt>uint64_t</tt>, the other side is
|
||||||
converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation
|
converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation
|
||||||
is performed. Otherwise both sides are converted to an
|
is performed. Otherwise, both sides are converted to an
|
||||||
<tt>int64_t</tt> and a signed arithmetic operation is performed. The
|
<tt>int64_t</tt> and a signed arithmetic operation is performed. The
|
||||||
result is a boxed 64 bit cdata object.<br>
|
result is a boxed 64 bit cdata object.<br>
|
||||||
|
|
||||||
@ -737,7 +737,7 @@ which is compatible with any other pointer type.</li>
|
|||||||
<li><b>64 bit integer comparison</b>: two cdata numbers, or a
|
<li><b>64 bit integer comparison</b>: two cdata numbers, or a
|
||||||
cdata number and a Lua number can be compared with each other. If one
|
cdata number and a Lua number can be compared with each other. If one
|
||||||
of them is an <tt>uint64_t</tt>, the other side is converted to an
|
of them is an <tt>uint64_t</tt>, the other side is converted to an
|
||||||
<tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise
|
<tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise,
|
||||||
both sides are converted to an <tt>int64_t</tt> and a signed
|
both sides are converted to an <tt>int64_t</tt> and a signed
|
||||||
comparison is performed.<br>
|
comparison is performed.<br>
|
||||||
|
|
||||||
@ -762,9 +762,9 @@ keys!</b>
|
|||||||
A cdata object is treated like any other garbage-collected object and
|
A cdata object is treated like any other garbage-collected object and
|
||||||
is hashed and compared by its address for table indexing. Since
|
is hashed and compared by its address for table indexing. Since
|
||||||
there's no interning for cdata value types, the same value may be
|
there's no interning for cdata value types, the same value may be
|
||||||
boxed in different cdata objects with different addresses. Thus
|
boxed in different cdata objects with different addresses. Thus,
|
||||||
<tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to
|
<tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to
|
||||||
the same hash slot and they certainly <b>do not</b> point to the same
|
the same hash slot, and they certainly <b>do not</b> point to the same
|
||||||
hash slot as <tt>t[2]</tt>.
|
hash slot as <tt>t[2]</tt>.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
@ -786,7 +786,7 @@ the resulting Lua number as a key when indexing tables.<br>
|
|||||||
One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to
|
One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to
|
||||||
the same slot as <tt>t[2]</tt>.</li>
|
the same slot as <tt>t[2]</tt>.</li>
|
||||||
|
|
||||||
<li>Otherwise use either <tt>tostring()</tt> on 64 bit integers
|
<li>Otherwise, use either <tt>tostring()</tt> on 64 bit integers
|
||||||
or complex numbers or combine multiple fields of a cdata aggregate to
|
or complex numbers or combine multiple fields of a cdata aggregate to
|
||||||
a Lua string (e.g. with
|
a Lua string (e.g. with
|
||||||
<a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then
|
<a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then
|
||||||
@ -794,7 +794,7 @@ use the resulting Lua string as a key when indexing tables.</li>
|
|||||||
|
|
||||||
<li>Create your own specialized hash table implementation using the
|
<li>Create your own specialized hash table implementation using the
|
||||||
C types provided by the FFI library, just like you would in
|
C types provided by the FFI library, just like you would in
|
||||||
C code. Ultimately this may give much better performance than the
|
C code. Ultimately, this may give much better performance than the
|
||||||
other alternatives or what a generic by-value hash table could
|
other alternatives or what a generic by-value hash table could
|
||||||
possibly provide.</li>
|
possibly provide.</li>
|
||||||
|
|
||||||
@ -860,7 +860,7 @@ garbage collector will automatically free the memory used by it (at
|
|||||||
the end of the next GC cycle).
|
the end of the next GC cycle).
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Please note that pointers themselves are cdata objects, however they
|
Please note, that pointers themselves are cdata objects, however they
|
||||||
are <b>not</b> followed by the garbage collector. So e.g. if you
|
are <b>not</b> followed by the garbage collector. So e.g. if you
|
||||||
assign a cdata array to a pointer, you must keep the cdata object
|
assign a cdata array to a pointer, you must keep the cdata object
|
||||||
holding the array alive as long as the pointer is still in use:
|
holding the array alive as long as the pointer is still in use:
|
||||||
@ -909,18 +909,18 @@ of the function pointer and the Lua function object (closure).
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
This can happen implicitly due to the usual conversions, e.g. when
|
This can happen implicitly due to the usual conversions, e.g. when
|
||||||
passing a Lua function to a function pointer argument. Or you can use
|
passing a Lua function to a function pointer argument. Or, you can use
|
||||||
<tt>ffi.cast()</tt> to explicitly cast a Lua function to a
|
<tt>ffi.cast()</tt> to explicitly cast a Lua function to a
|
||||||
C function pointer.
|
C function pointer.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Currently only certain C function types can be used as callback
|
Currently, only certain C function types can be used as callback
|
||||||
functions. Neither C vararg functions nor functions with
|
functions. Neither C vararg functions nor functions with
|
||||||
pass-by-value aggregate argument or result types are supported. There
|
pass-by-value aggregate argument or result types are supported. There
|
||||||
are no restrictions for the kind of Lua functions that can be called
|
are no restrictions on the kind of Lua functions that can be called
|
||||||
from the callback — no checks for the proper number of arguments
|
from the callback — no checks for the proper number of arguments
|
||||||
are made. The return value of the Lua function will be converted to the
|
are made. The return value of the Lua function will be converted to the
|
||||||
result type and an error will be thrown for invalid conversions.
|
result type, and an error will be thrown for invalid conversions.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
It's allowed to throw errors across a callback invocation, but it's not
|
It's allowed to throw errors across a callback invocation, but it's not
|
||||||
@ -981,7 +981,7 @@ convention cannot be automatically detected, unlike for
|
|||||||
<tt>__stdcall</tt> calls <em>to</em> Windows functions.
|
<tt>__stdcall</tt> calls <em>to</em> Windows functions.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
For some use cases it's necessary to free up the resources or to
|
For some use cases, it's necessary to free up the resources or to
|
||||||
dynamically redirect callbacks. Use an explicit cast to a
|
dynamically redirect callbacks. Use an explicit cast to a
|
||||||
C function pointer and keep the resulting cdata object. Then use
|
C function pointer and keep the resulting cdata object. Then use
|
||||||
the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a>
|
the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a>
|
||||||
@ -1034,7 +1034,7 @@ GUI application, which waits for user input most of the time, anyway.
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
For new designs <b>avoid push-style APIs</b>: a C function repeatedly
|
For new designs <b>avoid push-style APIs</b>: a C function repeatedly
|
||||||
calling a callback for each result. Instead <b>use pull-style APIs</b>:
|
calling a callback for each result. Instead, <b>use pull-style APIs</b>:
|
||||||
call a C function repeatedly to get a new result. Calls from Lua
|
call a C function repeatedly to get a new result. Calls from Lua
|
||||||
to C via the FFI are much faster than the other way round. Most well-designed
|
to C via the FFI are much faster than the other way round. Most well-designed
|
||||||
libraries already use pull-style APIs (read/write, get/put).
|
libraries already use pull-style APIs (read/write, get/put).
|
||||||
@ -1053,7 +1053,7 @@ function.
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Indexing a C library namespace object with a symbol name (a Lua
|
Indexing a C library namespace object with a symbol name (a Lua
|
||||||
string) automatically binds it to the library. First the symbol type
|
string) automatically binds it to the library. First, the symbol type
|
||||||
is resolved — it must have been declared with
|
is resolved — it must have been declared with
|
||||||
<a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the
|
<a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the
|
||||||
symbol address is resolved by searching for the symbol name in the
|
symbol address is resolved by searching for the symbol name in the
|
||||||
@ -1108,7 +1108,7 @@ Performance notice: the JIT compiler specializes to the identity of
|
|||||||
namespace objects and to the strings used to index it. This
|
namespace objects and to the strings used to index it. This
|
||||||
effectively turns function cdata objects into constants. It's not
|
effectively turns function cdata objects into constants. It's not
|
||||||
useful and actually counter-productive to explicitly cache these
|
useful and actually counter-productive to explicitly cache these
|
||||||
function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH it
|
function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH, it
|
||||||
<em>is</em> useful to cache the namespace itself, e.g. <tt>local C =
|
<em>is</em> useful to cache the namespace itself, e.g. <tt>local C =
|
||||||
ffi.C</tt>.
|
ffi.C</tt>.
|
||||||
</p>
|
</p>
|
||||||
@ -1133,14 +1133,14 @@ This behavior is inevitable, since the goal is to provide full
|
|||||||
interoperability with C code. Adding extra safety measures, like
|
interoperability with C code. Adding extra safety measures, like
|
||||||
bounds checks, would be futile. There's no way to detect
|
bounds checks, would be futile. There's no way to detect
|
||||||
misdeclarations of C functions, since shared libraries only
|
misdeclarations of C functions, since shared libraries only
|
||||||
provide symbol names, but no type information. Likewise there's no way
|
provide symbol names, but no type information. Likewise, there's no way
|
||||||
to infer the valid range of indexes for a returned pointer.
|
to infer the valid range of indexes for a returned pointer.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Again: the FFI library is a low-level library. This implies it needs
|
Again: the FFI library is a low-level library. This implies it needs
|
||||||
to be used with care, but it's flexibility and performance often
|
to be used with care, but it's flexibility and performance often
|
||||||
outweigh this concern. If you're a C or C++ developer, it'll be easy
|
outweigh this concern. If you're a C or C++ developer, it'll be easy
|
||||||
to apply your existing knowledge. OTOH writing code for the FFI
|
to apply your existing knowledge. OTOH, writing code for the FFI
|
||||||
library is not for the faint of heart and probably shouldn't be the
|
library is not for the faint of heart and probably shouldn't be the
|
||||||
first exercise for someone with little experience in Lua, C or C++.
|
first exercise for someone with little experience in Lua, C or C++.
|
||||||
</p>
|
</p>
|
||||||
@ -1168,7 +1168,7 @@ currently incomplete:
|
|||||||
<li>C declarations are not passed through a C pre-processor,
|
<li>C declarations are not passed through a C pre-processor,
|
||||||
yet.</li>
|
yet.</li>
|
||||||
<li>The C parser is able to evaluate most constant expressions
|
<li>The C parser is able to evaluate most constant expressions
|
||||||
commonly found in C header files. However it doesn't handle the
|
commonly found in C header files. However, it doesn't handle the
|
||||||
full range of C expression semantics and may fail for some
|
full range of C expression semantics and may fail for some
|
||||||
obscure constructs.</li>
|
obscure constructs.</li>
|
||||||
<li><tt>static const</tt> declarations only work for integer types
|
<li><tt>static const</tt> declarations only work for integer types
|
||||||
|
@ -81,7 +81,7 @@ of its functions:
|
|||||||
local ffi = require("ffi")
|
local ffi = require("ffi")
|
||||||
</pre>
|
</pre>
|
||||||
<p>
|
<p>
|
||||||
Please note this doesn't define an <tt>ffi</tt> variable in the table
|
Please note, this doesn't define an <tt>ffi</tt> variable in the table
|
||||||
of globals — you really need to use the local variable. The
|
of globals — you really need to use the local variable. The
|
||||||
<tt>require</tt> function ensures the library is only loaded once.
|
<tt>require</tt> function ensures the library is only loaded once.
|
||||||
</p>
|
</p>
|
||||||
@ -190,7 +190,7 @@ don't need to declare them as such.
|
|||||||
<span class="mark">⑤</span> The <tt>poll()</tt>
|
<span class="mark">⑤</span> The <tt>poll()</tt>
|
||||||
function takes a couple more arguments we're not going to use. You can
|
function takes a couple more arguments we're not going to use. You can
|
||||||
simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt>
|
simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt>
|
||||||
for the <tt>nfds</tt> parameter. Please note that the
|
for the <tt>nfds</tt> parameter. Please note, that the
|
||||||
number <tt>0</tt> <em>does not convert to a pointer value</em>,
|
number <tt>0</tt> <em>does not convert to a pointer value</em>,
|
||||||
unlike in C++. You really have to pass pointers to pointer arguments
|
unlike in C++. You really have to pass pointers to pointer arguments
|
||||||
and numbers to number arguments.
|
and numbers to number arguments.
|
||||||
@ -287,12 +287,12 @@ Here's the step-by-step explanation:
|
|||||||
<p>
|
<p>
|
||||||
<span class="mark">①</span> This defines some of the
|
<span class="mark">①</span> This defines some of the
|
||||||
C functions provided by zlib. For the sake of this example, some
|
C functions provided by zlib. For the sake of this example, some
|
||||||
type indirections have been reduced and it uses the pre-defined
|
type indirections have been reduced and it uses the predefined
|
||||||
fixed-size integer types, while still adhering to the zlib API/ABI.
|
fixed-size integer types, while still adhering to the zlib API/ABI.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
<span class="mark">②</span> This loads the zlib shared
|
<span class="mark">②</span> This loads the zlib shared
|
||||||
library. On POSIX systems it's named <tt>libz.so</tt> and usually
|
library. On POSIX systems, it's named <tt>libz.so</tt> and usually
|
||||||
comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any
|
comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any
|
||||||
missing standard prefixes/suffixes, we can simply load the
|
missing standard prefixes/suffixes, we can simply load the
|
||||||
<tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and
|
<tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and
|
||||||
@ -320,7 +320,7 @@ actual length that was used.
|
|||||||
<p>
|
<p>
|
||||||
In C you'd pass in the address of a local variable
|
In C you'd pass in the address of a local variable
|
||||||
(<tt>&buflen</tt>). But since there's no address-of operator in
|
(<tt>&buflen</tt>). But since there's no address-of operator in
|
||||||
Lua, we'll just pass in a one-element array. Conveniently it can be
|
Lua, we'll just pass in a one-element array. Conveniently, it can be
|
||||||
initialized with the maximum buffer size in one step. Calling the
|
initialized with the maximum buffer size in one step. Calling the
|
||||||
actual <tt>zlib.compress2</tt> function is then straightforward.
|
actual <tt>zlib.compress2</tt> function is then straightforward.
|
||||||
</p>
|
</p>
|
||||||
@ -344,7 +344,7 @@ for garbage collection and string interning.
|
|||||||
<span class="mark">⑥</span> The <tt>uncompress</tt>
|
<span class="mark">⑥</span> The <tt>uncompress</tt>
|
||||||
functions does the exact opposite of the <tt>compress</tt> function.
|
functions does the exact opposite of the <tt>compress</tt> function.
|
||||||
The compressed data doesn't include the size of the original string,
|
The compressed data doesn't include the size of the original string,
|
||||||
so this needs to be passed in. Otherwise no surprises here.
|
so this needs to be passed in. Otherwise, no surprises here.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
<span class="mark">⑦</span> The code, that makes use
|
<span class="mark">⑦</span> The code, that makes use
|
||||||
@ -378,7 +378,7 @@ Ok, so the <tt>ffi.*</tt> functions generally accept cdata objects
|
|||||||
wherever you'd want to use a number. That's why we get a away with
|
wherever you'd want to use a number. That's why we get a away with
|
||||||
passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua
|
passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua
|
||||||
library functions or modules don't know how to deal with this. So for
|
library functions or modules don't know how to deal with this. So for
|
||||||
maximum portability one needs to use <tt>tonumber()</tt> on returned
|
maximum portability, one needs to use <tt>tonumber()</tt> on returned
|
||||||
<tt>long</tt> results before passing them on. Otherwise the
|
<tt>long</tt> results before passing them on. Otherwise the
|
||||||
application might work on some systems, but would fail in a POSIX/x64
|
application might work on some systems, but would fail in a POSIX/x64
|
||||||
environment.
|
environment.
|
||||||
@ -450,7 +450,7 @@ the origin.
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
<span class="mark">④</span> If we run out of operators, we can
|
<span class="mark">④</span> If we run out of operators, we can
|
||||||
define named methods, too. Here the <tt>__index</tt> table defines an
|
define named methods, too. Here, the <tt>__index</tt> table defines an
|
||||||
<tt>area</tt> function. For custom indexing needs, one might want to
|
<tt>area</tt> function. For custom indexing needs, one might want to
|
||||||
define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead.
|
define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead.
|
||||||
</p>
|
</p>
|
||||||
@ -464,13 +464,13 @@ be used e.g. to create an array of points. The metamethods automatically
|
|||||||
apply to any and all uses of this type.
|
apply to any and all uses of this type.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Please note that the association with a metatable is permanent and
|
Please note, that the association with a metatable is permanent and
|
||||||
<b>the metatable must not be modified afterwards!</b> Ditto for the
|
<b>the metatable must not be modified afterwards!</b> Ditto for the
|
||||||
<tt>__index</tt> table.
|
<tt>__index</tt> table.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
<span class="mark">⑥</span> Here are some simple usage examples
|
<span class="mark">⑥</span> Here are some simple usage examples
|
||||||
for the point type and their expected results. The pre-defined
|
for the point type and their expected results. The predefined
|
||||||
operations (such as <tt>a.x</tt>) can be freely mixed with the newly
|
operations (such as <tt>a.x</tt>) can be freely mixed with the newly
|
||||||
defined metamethods. Note that <tt>area</tt> is a method and must be
|
defined metamethods. Note that <tt>area</tt> is a method and must be
|
||||||
called with the Lua syntax for methods: <tt>a:area()</tt>, not
|
called with the Lua syntax for methods: <tt>a:area()</tt>, not
|
||||||
@ -479,7 +479,7 @@ called with the Lua syntax for methods: <tt>a:area()</tt>, not
|
|||||||
<p>
|
<p>
|
||||||
The C type metamethod mechanism is most useful when used in
|
The C type metamethod mechanism is most useful when used in
|
||||||
conjunction with C libraries that are written in an object-oriented
|
conjunction with C libraries that are written in an object-oriented
|
||||||
style. Creators return a pointer to a new instance and methods take an
|
style. Creators return a pointer to a new instance, and methods take an
|
||||||
instance pointer as the first argument. Sometimes you can just point
|
instance pointer as the first argument. Sometimes you can just point
|
||||||
<tt>__index</tt> to the library namespace and <tt>__gc</tt> to the
|
<tt>__index</tt> to the library namespace and <tt>__gc</tt> to the
|
||||||
destructor and you're done. But often enough you'll want to add
|
destructor and you're done. But often enough you'll want to add
|
||||||
@ -565,7 +565,7 @@ end
|
|||||||
</pre>
|
</pre>
|
||||||
<p>
|
<p>
|
||||||
This turns them into indirect calls and generates bigger and slower
|
This turns them into indirect calls and generates bigger and slower
|
||||||
machine code. Instead you'll want to cache the namespace itself and
|
machine code. Instead, you'll want to cache the namespace itself and
|
||||||
rely on the JIT compiler to eliminate the lookups:
|
rely on the JIT compiler to eliminate the lookups:
|
||||||
</p>
|
</p>
|
||||||
<pre class="code">
|
<pre class="code">
|
||||||
|
@ -150,7 +150,7 @@ Contains the target architecture name:
|
|||||||
|
|
||||||
<h2 id="jit_opt"><tt>jit.opt.*</tt> — JIT compiler optimization control</h2>
|
<h2 id="jit_opt"><tt>jit.opt.*</tt> — JIT compiler optimization control</h2>
|
||||||
<p>
|
<p>
|
||||||
This sub-module provides the backend for the <tt>-O</tt> command line
|
This submodule provides the backend for the <tt>-O</tt> command line
|
||||||
option.
|
option.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
@ -170,7 +170,7 @@ which was one of the ways to enable optimization.
|
|||||||
|
|
||||||
<h2 id="jit_util"><tt>jit.util.*</tt> — JIT compiler introspection</h2>
|
<h2 id="jit_util"><tt>jit.util.*</tt> — JIT compiler introspection</h2>
|
||||||
<p>
|
<p>
|
||||||
This sub-module holds functions to introspect the bytecode, generated
|
This submodule holds functions to introspect the bytecode, generated
|
||||||
traces, the IR and the generated machine code. The functionality
|
traces, the IR and the generated machine code. The functionality
|
||||||
provided by this module is still in flux and therefore undocumented.
|
provided by this module is still in flux and therefore undocumented.
|
||||||
</p>
|
</p>
|
||||||
|
@ -84,7 +84,7 @@ or LuaJIT.
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
LuaJIT extends the standard Lua VM with new functionality and adds
|
LuaJIT extends the standard Lua VM with new functionality and adds
|
||||||
several extension modules. Please note this page is only about
|
several extension modules. Please note, this page is only about
|
||||||
<em>functional</em> enhancements and not about performance enhancements,
|
<em>functional</em> enhancements and not about performance enhancements,
|
||||||
such as the optimized VM, the faster interpreter or the JIT compiler.
|
such as the optimized VM, the faster interpreter or the JIT compiler.
|
||||||
</p>
|
</p>
|
||||||
@ -185,7 +185,7 @@ usage. See also the
|
|||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The generated bytecode is portable and can be loaded on any architecture
|
The generated bytecode is portable and can be loaded on any architecture
|
||||||
that LuaJIT supports, independent of word size or endianess. However the
|
that LuaJIT supports, independent of word size or endianess. However, the
|
||||||
bytecode compatibility versions must match. Bytecode stays compatible
|
bytecode compatibility versions must match. Bytecode stays compatible
|
||||||
for dot releases (x.y.0 → x.y.1), but may change with major or
|
for dot releases (x.y.0 → x.y.1), but may change with major or
|
||||||
minor releases (2.0 → 2.1) or between any beta release. Foreign
|
minor releases (2.0 → 2.1) or between any beta release. Foreign
|
||||||
@ -197,7 +197,7 @@ bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded.
|
|||||||
LuaJIT uses a Tausworthe PRNG with period 2^223 to implement
|
LuaJIT uses a Tausworthe PRNG with period 2^223 to implement
|
||||||
<tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of
|
<tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of
|
||||||
the PRNG results is much superior compared to the standard Lua
|
the PRNG results is much superior compared to the standard Lua
|
||||||
implementation which uses the platform-specific ANSI rand().
|
implementation, which uses the platform-specific ANSI rand().
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The PRNG generates the same sequences from the same seeds on all
|
The PRNG generates the same sequences from the same seeds on all
|
||||||
@ -215,7 +215,7 @@ Important: Neither this nor any other PRNG based on the simplistic
|
|||||||
<h3 id="io"><tt>io.*</tt> functions handle 64 bit file offsets</h3>
|
<h3 id="io"><tt>io.*</tt> functions handle 64 bit file offsets</h3>
|
||||||
<p>
|
<p>
|
||||||
The file I/O functions in the standard <tt>io.*</tt> library handle
|
The file I/O functions in the standard <tt>io.*</tt> library handle
|
||||||
64 bit file offsets. In particular this means it's possible
|
64 bit file offsets. In particular, this means it's possible
|
||||||
to open files larger than 2 Gigabytes and to reposition or obtain
|
to open files larger than 2 Gigabytes and to reposition or obtain
|
||||||
the current file position for offsets beyond 2 GB
|
the current file position for offsets beyond 2 GB
|
||||||
(<tt>fp:seek()</tt> method).
|
(<tt>fp:seek()</tt> method).
|
||||||
|
@ -116,7 +116,7 @@ Direct3D version 10 or higher do not show this behavior anymore.
|
|||||||
Consider testing your application with older versions, too.<br>
|
Consider testing your application with older versions, too.<br>
|
||||||
|
|
||||||
Similarly, the Borland/Delphi runtime modifies the FPU control word and
|
Similarly, the Borland/Delphi runtime modifies the FPU control word and
|
||||||
enables FP exceptions. Of course this violates the Windows ABI, too.
|
enables FP exceptions. Of course, this violates the Windows ABI, too.
|
||||||
Please check the Delphi docs for the Set8087CW method.</dd>
|
Please check the Delphi docs for the Set8087CW method.</dd>
|
||||||
</dl>
|
</dl>
|
||||||
|
|
||||||
@ -126,7 +126,7 @@ Please check the Delphi docs for the Set8087CW method.</dd>
|
|||||||
ignored by compiled code. If your program is running in a tight loop
|
ignored by compiled code. If your program is running in a tight loop
|
||||||
and never falls back to the interpreter, the debug hook never runs and
|
and never falls back to the interpreter, the debug hook never runs and
|
||||||
can't throw the "interrupted!" error.<br>
|
can't throw the "interrupted!" error.<br>
|
||||||
You have to press Ctrl-C twice to get stop your program. That's similar
|
You have to press Ctrl-C twice to stop your program. That's similar
|
||||||
to when it's stuck running inside a C function under the Lua interpreter.</dd>
|
to when it's stuck running inside a C function under the Lua interpreter.</dd>
|
||||||
</dl>
|
</dl>
|
||||||
|
|
||||||
@ -146,7 +146,7 @@ so it doesn't rely on the key order. Or sort the table keys, if you must.</dd>
|
|||||||
<dl id="sandbox">
|
<dl id="sandbox">
|
||||||
<dt>Q: Can Lua code be safely sandboxed?</dt>
|
<dt>Q: Can Lua code be safely sandboxed?</dt>
|
||||||
<dd>
|
<dd>
|
||||||
Maybe for an extremly restricted subset of Lua and if you relentlessly
|
Maybe for an extremely restricted subset of Lua and if you relentlessly
|
||||||
scrutinize every single interface function you offer to the untrusted code.<br>
|
scrutinize every single interface function you offer to the untrusted code.<br>
|
||||||
|
|
||||||
Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks),
|
Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks),
|
||||||
|
@ -317,7 +317,7 @@ The recommended way to fetch the latest version is to do a pull from
|
|||||||
the git repository.
|
the git repository.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Alternatively download the latest source package of LuaJIT (pick the .tar.gz).
|
Alternatively, download the latest source package of LuaJIT (pick the .tar.gz).
|
||||||
Move it to a directory of your choice, open a terminal window and change
|
Move it to a directory of your choice, open a terminal window and change
|
||||||
to this directory. Now unpack the archive and change to the newly created
|
to this directory. Now unpack the archive and change to the newly created
|
||||||
directory (replace XX.YY.ZZ with the version you downloaded):
|
directory (replace XX.YY.ZZ with the version you downloaded):
|
||||||
@ -475,7 +475,7 @@ important to compile with the proper CPU or architecture settings. You
|
|||||||
can specify these when building the toolchain yourself. Or add
|
can specify these when building the toolchain yourself. Or add
|
||||||
<tt>-mcpu=...</tt> or <tt>-march=...</tt> to <tt>TARGET_CFLAGS</tt>. For
|
<tt>-mcpu=...</tt> or <tt>-march=...</tt> to <tt>TARGET_CFLAGS</tt>. For
|
||||||
ARM it's important to have the correct <tt>-mfloat-abi=...</tt> setting,
|
ARM it's important to have the correct <tt>-mfloat-abi=...</tt> setting,
|
||||||
too. Otherwise LuaJIT may not run at the full performance of your target
|
too. Otherwise, LuaJIT may not run at the full performance of your target
|
||||||
CPU.
|
CPU.
|
||||||
</p>
|
</p>
|
||||||
<pre class="code">
|
<pre class="code">
|
||||||
@ -619,7 +619,7 @@ allocator from your system (no support for this on 64 bit architectures).</
|
|||||||
of calling <tt>luaopen_base</tt> etc. directly.</li>
|
of calling <tt>luaopen_base</tt> etc. directly.</li>
|
||||||
<li>To change or extend the list of standard libraries to load, copy
|
<li>To change or extend the list of standard libraries to load, copy
|
||||||
<tt>src/lib_init.c</tt> to your project and modify it accordingly.
|
<tt>src/lib_init.c</tt> to your project and modify it accordingly.
|
||||||
Make sure the <tt>jit</tt> library is loaded or the JIT compiler
|
Make sure the <tt>jit</tt> library is loaded, or the JIT compiler
|
||||||
will not be activated.</li>
|
will not be activated.</li>
|
||||||
<li>The <tt>bit.*</tt> module for bitwise operations
|
<li>The <tt>bit.*</tt> module for bitwise operations
|
||||||
is already built-in. There's no need to statically link
|
is already built-in. There's no need to statically link
|
||||||
@ -638,7 +638,7 @@ in unspeakable ways.
|
|||||||
There should be absolutely no need to patch <tt>luaconf.h</tt> or any
|
There should be absolutely no need to patch <tt>luaconf.h</tt> or any
|
||||||
of the Makefiles. And please do not hand-pick files for your packages —
|
of the Makefiles. And please do not hand-pick files for your packages —
|
||||||
simply use whatever <tt>make install</tt> creates. There's a reason
|
simply use whatever <tt>make install</tt> creates. There's a reason
|
||||||
for all of the files <em>and</em> directories it creates.
|
for all the files <em>and</em> directories it creates.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
The build system uses GNU make and auto-detects most settings based on
|
The build system uses GNU make and auto-detects most settings based on
|
||||||
|
@ -179,7 +179,7 @@ written in Lua. They are mainly used for debugging the JIT compiler
|
|||||||
itself. For a description of their options and output format, please
|
itself. For a description of their options and output format, please
|
||||||
read the comment block at the start of their source.
|
read the comment block at the start of their source.
|
||||||
They can be found in the <tt>lib</tt> directory of the source
|
They can be found in the <tt>lib</tt> directory of the source
|
||||||
distribution or installed under the <tt>jit</tt> directory. By default
|
distribution or installed under the <tt>jit</tt> directory. By default,
|
||||||
this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX
|
this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX
|
||||||
systems (replace XX.YY.ZZ by the installed version).
|
systems (replace XX.YY.ZZ by the installed version).
|
||||||
</p>
|
</p>
|
||||||
@ -211,7 +211,7 @@ to a specific value.
|
|||||||
You can either use this option multiple times (like <tt>-Ocse
|
You can either use this option multiple times (like <tt>-Ocse
|
||||||
-O-dce -Ohotloop=10</tt>) or separate several settings with a comma
|
-O-dce -Ohotloop=10</tt>) or separate several settings with a comma
|
||||||
(like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from
|
(like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from
|
||||||
left to right and later settings override earlier ones. You can freely
|
left to right, and later settings override earlier ones. You can freely
|
||||||
mix the three forms, but note that setting an optimization level
|
mix the three forms, but note that setting an optimization level
|
||||||
overrides all earlier flags.
|
overrides all earlier flags.
|
||||||
</p>
|
</p>
|
||||||
|
@ -79,7 +79,7 @@ Known incompatibilities and issues in LuaJIT 2.0:
|
|||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
There are some differences in <b>implementation-defined</b> behavior.
|
There are some differences in <b>implementation-defined</b> behavior.
|
||||||
These either have a good reason, are arbitrary design choices
|
These either have a good reason, are arbitrary design choices,
|
||||||
or are due to quirks in the VM. The latter cases may get fixed if a
|
or are due to quirks in the VM. The latter cases may get fixed if a
|
||||||
demonstrable need is shown.
|
demonstrable need is shown.
|
||||||
</li>
|
</li>
|
||||||
@ -89,7 +89,7 @@ hooks for non-Lua functions) and shows slightly different behavior
|
|||||||
in LuaJIT (no per-coroutine hooks, no tail call counting).
|
in LuaJIT (no per-coroutine hooks, no tail call counting).
|
||||||
</li>
|
</li>
|
||||||
<li>
|
<li>
|
||||||
Currently some <b>out-of-memory</b> errors from <b>on-trace code</b> are not
|
Currently, some <b>out-of-memory</b> errors from <b>on-trace code</b> are not
|
||||||
handled correctly. The error may fall through an on-trace
|
handled correctly. The error may fall through an on-trace
|
||||||
<tt>pcall</tt> or it may be passed on to the function set with
|
<tt>pcall</tt> or it may be passed on to the function set with
|
||||||
<tt>lua_atpanic</tt> on x64.
|
<tt>lua_atpanic</tt> on x64.
|
||||||
|
Loading…
Reference in New Issue
Block a user