Remove a (sometimes) wrong assertion in luaJIT_findpc().
-
DynASM now allows labels for displacements and .aword.
-
Fix some compiler warnings for DynASM glue (internal API change).
-
Correct naming for SSSE3 (temporarily known as SSE4) in DynASM and x86 disassembler.
-
The loadable debug modules now handle redirection to stdout
-(e.g. -j trace=-).
-
-
-
LuaJIT 1.1.2 — 2006-06-24
-
-
Fix MSVC inline assembly: use only local variables with
-lua_number2int().
-
Fix "attempt to call a thread value" bug on Mac OS X:
-make values of consts used as lightuserdata keys unique
-to avoid joining by the compiler/linker.
The C stack is kept 16 byte aligned (faster).
-Mandatory for Mac OS X on Intel, too.
-
Faster calling conventions for internal C helper functions.
-
Better instruction scheduling for function prologue, OP_CALL and
-OP_RETURN.
-
-
-
Miscellaneous optimizations:
-
-
Faster loads of FP constants. Remove narrow-to-wide store-to-load
-forwarding stalls.
-
Use (scalar) SSE2 ops (if the CPU supports it) to speed up slot moves
-and FP to integer conversions.
-
Optimized the two-argument form of OP_CONCAT (a..b).
-
Inlined OP_MOD (a%b).
-With better accuracy than the C variant, too.
-
Inlined OP_POW (a^b). Unroll x^k or
-use k^x = 2^(log2(k)*x) or call pow().
-
-
-
Changes in the optimizer:
-
-
Improved hinting for table keys derived from table values
-(t1[t2[x]]).
-
Lookup hinting now works with arbitrary object types and
-supports index chains, too.
-
Generate type hints for arithmetic and comparison operators,
-OP_LEN, OP_CONCAT and OP_FORPREP.
-
Remove several hint definitions in favour of a generic COMBINE hint.
-
Complete rewrite of jit.opt_inline module
-(ex jit.opt_lib).
-
-
-
Use adaptive deoptimization:
-
-
If runtime verification of a contract fails, the affected
-instruction is recompiled and patched on-the-fly.
-Regular programs will trigger deoptimization only occasionally.
-
This avoids generating code for uncommon fallback cases
-most of the time. Generated code is up to 30% smaller compared to
-LuaJIT 1.0.3.
-
Deoptimization is used for many opcodes and contracts:
-
-
OP_CALL, OP_TAILCALL: type mismatch for callable.
-
Inlined calls: closure mismatch, parameter number and type mismatches.
-
OP_GETTABLE, OP_SETTABLE: table or key type and range mismatches.
-
All arithmetic and comparison operators, OP_LEN, OP_CONCAT,
-OP_FORPREP: operand type and range mismatches.
-
-
Complete redesign of the debug and traceback info
-(bytecode ↔ mcode) to support deoptimization.
-Much more flexible and needs only 50% of the space.
-
The modules jit.trace, jit.dumphints and
-jit.dump handle deoptimization.
-
-
-
Inlined many popular library functions
-(for commonly used arguments only):
-
-
Most math.* functions (the 18 most used ones)
-[2x-10x faster].
-
string.len, string.sub and string.char
-[2x-10x faster].
-
table.insert, table.remove and table.getn
-[3x-5x faster].
-
coroutine.yield and coroutine.resume
-[3x-5x faster].
-
pairs, ipairs and the corresponding iterators
-[8x-15x faster].
-
-
-
Changes in the core and loadable modules and the stand-alone executable:
-
-
Added jit.version, jit.version_num
-and jit.arch.
-
Reorganized some internal API functions (jit.util.*mcode*).
-
The -j dump output now shows JSUB names, too.
-
New x86 disassembler module written in pure Lua. No dependency
-on ndisasm anymore. Flexible API, very compact (500 lines)
-and complete (x87, MMX, SSE, SSE2, SSE3, SSSE3, privileged instructions).
-
luajit -v prints the LuaJIT version and copyright
-on a separate line.
-
-
-
Added SSE, SSE2, SSE3 and SSSE3 support to DynASM.
-
Miscellaneous doc changes. Added a section about
-embedding LuaJIT.
Status
@@ -89,8 +90,8 @@ other Lua/C API functions).
The third argument specifies the mode, which is 'or'ed with a flag.
-The flag can be LUAJIT_MODE_OFF to turn a feature on,
-LUAJIT_MODE_ON to turn a feature off, or
+The flag can be LUAJIT_MODE_OFF to turn a feature off,
+LUAJIT_MODE_ON to turn a feature on, or
LUAJIT_MODE_FLUSH to flush cached code.
@@ -177,7 +178,7 @@ Also note that this mechanism is not without overhead.
Status
@@ -466,6 +467,10 @@ otherwise. The following parameters are currently defined:
eabi
EABI variant of the standard ABI
win
Windows variant of the standard ABI
+
+
uwp
Universal Windows Platform
+
+
gc64
64 bit GC references
ffi.os
@@ -542,8 +547,8 @@ corresponding ctype.
The parser for Lua source code treats numeric literals with the
suffixes LL or ULL as signed or unsigned 64 bit
integers. Case doesn't matter, but uppercase is recommended for
-readability. It handles both decimal (42LL) and hexadecimal
-(0x2aLL) literals.
+readability. It handles decimal (42LL), hexadecimal
+(0x2aLL) and binary (0b101010LL) literals.
The imaginary part of complex numbers can be specified by suffixing
@@ -556,7 +561,7 @@ named i.
Status
@@ -183,6 +184,8 @@ a typedef, except re-declarations will be ignored):
uint16_t, uint32_t, uint64_t,
intptr_t, uintptr_t.
+
From <unistd.h> (POSIX): ssize_t.
+
You're encouraged to use these types in preference to
@@ -730,6 +733,22 @@ You'll have to explicitly convert a 64 bit integer to a Lua
number (e.g. for regular floating-point calculations) with
tonumber(). But note this may incur a precision loss.
+
64 bit bitwise operations: the rules for 64 bit
+arithmetic operators apply analogously.
+
+Unlike the other bit.* operations, bit.tobit()
+converts a cdata number via int64_t to int32_t and
+returns a Lua number.
+
+For bit.band(), bit.bor() and bit.bxor(), the
+conversion to int64_t or uint64_t applies to
+all arguments, if any argument is a cdata number.
+
+For all other operations, only the first argument is used to determine
+the output type. This implies that a cdata number as a shift count for
+shifts and rotates is accepted, but that alone does not cause
+a cdata number output.
+
Comparisons of cdata objects
@@ -844,7 +863,7 @@ place of a type, you'd need to use ffi.typeof("int") instead.
The main use for parameterized types are libraries implementing abstract
data types
-(» example),
+(example),
similar to what can be achieved with C++ template metaprogramming.
Another use case are derived types of anonymous structs, which avoids
pollution of the global struct namespace.
@@ -1201,14 +1220,12 @@ The following operations are currently not compiled and may exhibit
suboptimal performance, especially when used in inner loops:
-
Bitfield accesses and initializations.
Vector operations.
Table initializers.
Initialization of nested struct/union types.
-
Allocations of variable-length arrays or structs.
-
Allocations of C types with a size > 128 bytes or an
-alignment > 8 bytes.
-
Conversions from lightuserdata to void *.
+
Non-default initialization of VLA/VLS or large C types
+(> 128 bytes or > 16 array elements.
+
Bitfield initializations.
Pointer differences for element sizes that are not a power of
two.
Calls to C functions with aggregates passed or returned by
@@ -1224,7 +1241,6 @@ value.
+LuaJIT has an integrated statistical profiler with very low overhead. It
+allows sampling the currently executing stack and other parameters in
+regular intervals.
+
+
+The integrated profiler can be accessed from three levels:
+
+The bundled high-level profiler offers basic profiling functionality. It
+generates simple textual summaries or source code annotations. It can be
+accessed with the -jp command line option
+or from Lua code by loading the underlying jit.p module.
+
+
+To cut to the chase — run this to get a CPU usage profile by
+function name:
+
+
+luajit -jp myapp.lua
+
+
+It's not a stated goal of the bundled profiler to add every
+possible option or to cater for special profiling needs. The low-level
+profiler APIs are documented below. They may be used by third-party
+authors to implement advanced functionality, e.g. IDE integration or
+graphical profilers.
+
+
+Note: Sampling works for both interpreted and JIT-compiled code. The
+results for JIT-compiled code may sometimes be surprising. LuaJIT
+heavily optimizes and inlines Lua code — there's no simple
+one-to-one correspondence between source code lines and the sampled
+machine code.
+
+
+
-jp=[options[,output]]
+
+The -jp command line option starts the high-level profiler.
+When the application run by the command line terminates, the profiler
+stops and writes the results to stdout or to the specified
+output file.
+
+
+The options argument specifies how the profiling is to be
+performed:
+
+
+
f — Stack dump: function name, otherwise module:line.
+This is the default mode.
r — Show raw sample counts. Default: show percentages.
+
a — Annotate excerpts from source code files.
+
A — Annotate complete source code files.
+
G — Produce raw output suitable for graphical tools.
+
m<number> — Minimum sample percentage to be shown.
+Default: 3%.
+
i<number> — Sampling interval in milliseconds.
+Default: 10ms.
+Note: The actual sampling precision is OS-dependent.
+
+
+The default output for -jp is a list of the most CPU consuming
+spots in the application. Increasing the stack dump depth with (say)
+-jp=2 may help to point out the main callers or callees of
+hotspots. But sample aggregation is still flat per unique stack dump.
+
+
+To get a two-level view (split view) of callers/callees, use
+-jp=s or -jp=-s. The percentages shown for the second
+level are relative to the first level.
+
+
+To see how much time is spent in each line relative to a function, use
+-jp=fl.
+
+
+To see how much time is spent in different VM states or
+zones, use -jp=v or -jp=z.
+
+
+Combinations of v/z with f/F/l produce two-level
+views, e.g. -jp=vf or -jp=fv. This shows the time
+spent in a VM state or zone vs. hotspots. This can be used to answer
+questions like "Which time consuming functions are only interpreted?" or
+"What's the garbage collector overhead for a specific function?".
+
+
+Multiple options can be combined — but not all combinations make
+sense, see above. E.g. -jp=3si4m1 samples three stack levels
+deep in 4ms intervals and shows a split view of the CPU consuming
+functions and their callers with a 1% threshold.
+
+
+Source code annotations produced by -jp=a or -jp=A are
+always flat and at the line level. Obviously, the source code files need
+to be readable by the profiler script.
+
+
+The high-level profiler can also be started and stopped from Lua code with:
+
+Zones can be used to provide information about different parts of an
+application to the high-level profiler. E.g. a game could make use of an
+"AI" zone, a "PHYS" zone, etc. Zones are hierarchical,
+organized as a stack.
+
+
+The jit.zone module needs to be loaded explicitly:
+
+
+local zone = require("jit.zone")
+
+
+
zone("name") pushes a named zone to the zone stack.
+
zone() pops the current zone from the zone stack and
+returns its name.
+
zone:get() returns the current zone name or nil.
+
zone:flush() flushes the zone stack.
+
+
+To show the time spent in each zone use -jp=z. To show the time
+spent relative to hotspots use e.g. -jp=zf or -jp=fz.
+
+
+
Low-level Lua API
+
+The jit.profile module gives access to the low-level API of the
+profiler from Lua code. This module needs to be loaded explicitly:
+
+local profile = require("jit.profile")
+
+
+This module can be used to implement your own higher-level profiler.
+A typical profiling run starts the profiler, captures stack dumps in
+the profiler callback, adds them to a hash table to aggregate the number
+of samples, stops the profiler and then analyzes all of the captured
+stack dumps. Other parameters can be sampled in the profiler callback,
+too. But it's important not to spend too much time in the callback,
+since this may skew the statistics.
+
+
+
profile.start(mode, cb)
+— Start profiler
+
+This function starts the profiler. The mode argument is a
+string holding options:
+
+
+
f — Profile with precision down to the function level.
+
l — Profile with precision down to the line level.
+
i<number> — Sampling interval in milliseconds (default
+10ms).
+Note: The actual sampling precision is OS-dependent.
+
+
+
+The cb argument is a callback function which is called with
+three arguments: (thread, samples, vmstate). The callback is
+called on a separate coroutine, the thread argument is the
+state that holds the stack to sample for profiling. Note: do
+not modify the stack of that state or call functions on it.
+
+
+samples gives the number of accumulated samples since the last
+callback (usually 1).
+
+
+vmstate holds the VM state at the time the profiling timer
+triggered. This may or may not correspond to the state of the VM when
+the profiling callback is called. The state is either 'N'
+native (compiled) code, 'I' interpreted code, 'C'
+C code, 'G' the garbage collector, or 'J' the JIT
+compiler.
+
+This function allows taking stack dumps in an efficient manner. It
+returns a string with a stack dump for the thread (coroutine),
+formatted according to the fmt argument:
+
+
+
p — Preserve the full path for module names. Otherwise
+only the file name is used.
+
f — Dump the function name if it can be derived. Otherwise
+use module:line.
+
F — Ditto, but dump module:name.
+
l — Dump module:line.
+
Z — Zap the following characters for the last dumped
+frame.
+
All other characters are added verbatim to the output string.
+
+
+The depth argument gives the number of frames to dump, starting
+at the topmost frame of the thread. A negative number dumps the frames in
+inverse order.
+
+
+The first example prints a list of the current module names and line
+numbers of up to 10 frames in separate lines. The second example prints
+semicolon-separated function names for all frames (up to 100) in inverse
+order:
+
+This function starts the profiler. See
+above for a description of the mode argument.
+
+
+The cb argument is a callback function with the following
+declaration:
+
+
+typedef void (*luaJIT_profile_callback)(void *data, lua_State *L,
+ int samples, int vmstate);
+
+
+data is available for use by the callback. L is the
+state that holds the stack to sample for profiling. Note: do
+not modify this stack or call functions on this stack —
+use a separate coroutine for this purpose. See
+above for a description of samples and vmstate.
+
+
+
luaJIT_profile_stop(L)
+— Stop profiler
+
+This function stops the profiler.
+
+
+
p = luaJIT_profile_dumpstack(L, fmt, depth, len)
+— Dump stack
+
+This function allows taking stack dumps in an efficient manner.
+See above for a description of fmt
+and depth.
+
+
+This function returns a const char * pointing to a
+private string buffer of the profiler. The int *len
+argument returns the length of the output string. The buffer is
+overwritten on the next call and deallocated when the profiler stops.
+You either need to consume the content immediately or copy it for later
+use.
+
Status
@@ -113,6 +114,9 @@ bit.lshift bit.rshift bit.arshift bit.rol bit.ror bit.bswap
This module is a LuaJIT built-in — you don't need to download or
install Lua BitOp. The Lua BitOp site has full documentation for all
» Lua BitOp API functions.
+The FFI adds support for
+64 bit bitwise operations,
+using the same API functions.
Please make sure to require the module before using any of
@@ -146,6 +150,11 @@ LuaJIT adds some
extra functions to the Lua/C API.
tonumber() etc. use builtin string to number conversion
All string-to-number conversions consistently convert integer and
-floating-point inputs in decimal and hexadecimal on all platforms.
+floating-point inputs in decimal, hexadecimal and binary on all platforms.
strtod() is not used anymore, which avoids numerous
problems with poor C library implementations. The builtin conversion
function provides full precision according to the IEEE-754 standard, it
@@ -197,6 +206,36 @@ 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
bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded.
+
+Note: LJ_GC64 mode requires a different frame layout, which implies
+a different, incompatible bytecode format for all 64 bit ports. This may be
+rectified in the future.
+
+
+
table.new(narray, nhash) allocates a pre-sized table
+
+An extra library function table.new() can be made available via
+require("table.new"). This creates a pre-sized table, just like
+the C API equivalent lua_createtable(). This is useful for big
+tables if the final table size is known and automatic table resizing is
+too expensive.
+
+
+
table.clear(tab) clears a table
+
+An extra library function table.clear() can be made available
+via require("table.clear"). This clears all keys and values
+from a table, but preserves the allocated array/hash sizes. This is
+useful when a table, which is linked from multiple places, needs to be
+cleared and/or when recycling a table for use by the same context. This
+avoids managing backlinks, saves an allocation and the overhead of
+incremental array/hash part growth.
+
+
+Please note this function is meant for very specific situations. In most
+cases it's better to replace the (usually single) link with a new table
+and let the GC do its work.
+
Enhanced PRNG for math.random()
@@ -213,6 +252,10 @@ for every call. The result is uniformly distributed between 0.0 and 1.0.
It's correctly scaled up and rounded for math.random(n [,m]) to
preserve uniformity.
+
+Important: Neither this nor any other PRNG based on the simplistic
+math.random() API is suitable for cryptographic use.
+
io.* functions handle 64 bit file offsets
@@ -271,6 +314,26 @@ indexes for varargs.
debug.getupvalue() and debug.setupvalue() handle
C functions.
Note: this provides only partial compatibility with Lua 5.2 at the
@@ -304,6 +369,21 @@ Lua 5.1, which prevents implementing features that would otherwise
break the Lua/C API and ABI (e.g. _ENV).
+
Extensions from Lua 5.3
+
+LuaJIT supports some extensions from Lua 5.3:
+
+
Unicode escape '\u{XX...}' embeds the UTF-8 encoding in string literals.
+
The argument table arg can be read (and modified) by LUA_INIT and -e chunks.
+
io.read() and file:read() accept formats with or without a leading *.
+
assert() accepts any type of error object.
+
table.move(a1, f, e, t [,a2]).
+
coroutine.isyieldable().
+
Lua/C API extensions:
+lua_isyieldable()
+
+
+
C++ Exception Interoperability
LuaJIT has built-in support for interoperating with C++ exceptions.
@@ -318,25 +398,30 @@ the toolchain used to compile LuaJIT:
POSIX/x64, DWARF2 unwinding
-
GCC 4.3+
+
GCC 4.3+, Clang
Full
-
Other platforms, DWARF2 unwinding
-
GCC
-
Limited
+
ARM -DLUAJIT_UNWIND_EXTERNAL
+
GCC, Clang
+
Full
+
Other platforms, DWARF2 unwinding
+
GCC, Clang
+
Limited
+
+
Windows/x64
MSVC or WinSDK
Full
-
+
Windows/x86
Any
-
No
+
Full
-
+
Other platforms
Other compilers
No
@@ -385,20 +470,12 @@ C++ destructors.
Lua errors cannot be caught on the C++ side.
Throwing Lua errors across C++ frames will not call
C++ destructors.
-
Additionally, on Windows/x86 with SEH-based C++ exceptions:
-it's not safe to throw a Lua error across any frames containing
-a C++ function with any try/catch construct or using variables with
-(implicit) destructors. This also applies to any functions which may be
-inlined in such a function. It doesn't matter whether lua_error()
-is called inside or outside of a try/catch or whether any object actually
-needs to be destroyed: the SEH chain is corrupted and this will eventually
-lead to the termination of the process.
src/Makefile has settings for compiling LuaJIT
under POSIX, MinGW or Cygwin.
src/msvcbuild.bat has settings for compiling LuaJIT with
-MSVC or WinSDK.
+MSVC (Visual Studio).
Please read the instructions given in these files, before changing
any settings.
+
+All LuaJIT 64 bit ports use 64 bit GC objects by default (LJ_GC64).
+For x64, you can select the old 32-on-64 bit mode by adding
+XCFLAGS=-DLUAJIT_DISABLE_GC64 to the make command.
+Please check the note about the
+bytecode format differences, too.
+
POSIX Systems (Linux, OSX, *BSD etc.)
Prerequisites
@@ -200,7 +208,7 @@ which is probably the default on your system, anyway. Simply run:
make
-This always builds a native x86, x64 or PPC binary, depending on the host OS
+This always builds a native binary, depending on the host OS
you're running this command on. Check the section on
cross-compilation for more options.
@@ -213,8 +221,8 @@ You can add an extra prefix to the search paths by appending the
make PREFIX=/home/myself/lj2
-Note for OSX: if the MACOSX_DEPLOYMENT_TARGET environment
-variable is not set, then it's forced to 10.4.
+Note for OSX: you must set the MACOSX_DEPLOYMENT_TARGET
+environment variable to a value supported by your toolchain.
Installing LuaJIT
@@ -244,17 +252,7 @@ Either install one of the open source SDKs
(» MinGW or
» Cygwin), which come with a modified
GCC plus the required development headers.
-
-
-Or install Microsoft's Visual C++ (MSVC). The freely downloadable
-» Express Edition
-works just fine, but only contains an x86 compiler.
-
-
-The freely downloadable
-» Windows SDK
-only comes with command line tools, but this is all you need to build LuaJIT.
-It contains x86 and x64 compilers.
+Or install Microsoft's Visual Studio (MSVC).
Next, download the source package and unpack it using an archive manager
@@ -262,7 +260,7 @@ Next, download the source package and unpack it using an archive manager
Building with MSVC
-Open a "Visual Studio .NET Command Prompt", cd to the
+Open a "Visual Studio Command Prompt" (either x86 or x64), cd to the
directory where you've unpacked the sources and run these commands:
@@ -270,30 +268,7 @@ cd src
msvcbuild
-Then follow the installation instructions below.
-
-
Building with the Windows SDK
-
-Open a "Windows SDK Command Shell" and select the x86 compiler:
-
-
-setenv /release /x86
-
-
-Or select the x64 compiler:
-
-
-setenv /release /x64
-
-
-Then cd to the directory where you've unpacked the sources
-and run these commands:
-
-
-cd src
-msvcbuild
-
-
+Check the msvcbuild.bat file for more options.
Then follow the installation instructions below.
Building with MinGW or Cygwin
@@ -331,25 +306,36 @@ directory where luajit.exe is installed
Cross-compiling LuaJIT
-The GNU Makefile-based build system allows cross-compiling on any host
-for any supported target, as long as both architectures have the same
-pointer size. If you want to cross-compile to any 32 bit target on an
-x64 OS, you need to install the multilib development package (e.g.
-libc6-dev-i386 on Debian/Ubuntu) and build a 32 bit host part
-(HOST_CC="gcc -m32").
+First, let's clear up some terminology:
+
+
Host: This is your development system, usually based on a x64 or x86 CPU.
+
Target: This is the target system you want LuaJIT to run on, e.g. Android/ARM.
+
Toolchain: This comprises a C compiler, linker, assembler and a matching C library.
+
Host (or system) toolchain: This is the toolchain used to build native binaries for your host system.
+
Cross-compile toolchain: This is the toolchain used to build binaries for the target system. They can only be run on the target system.
+
+
+The GNU Makefile-based build system allows cross-compiling on any host
+for any supported target:
+
+
+
Yes, you need a toolchain for both your host and your target!
+
Both host and target architectures must have the same pointer size.
+
E.g. if you want to cross-compile to a 32 bit target on a 64 bit host, you need to install the multilib development package (e.g. libc6-dev-i386 on Debian/Ubuntu) and build a 32 bit host part (HOST_CC="gcc -m32").
+
64 bit targets always require compilation on a 64 bit host.
+
You need to specify TARGET_SYS whenever the host OS and the
-target OS differ, or you'll get assembler or linker errors. E.g. if
-you're compiling on a Windows or OSX host for embedded Linux or Android,
-you need to add TARGET_SYS=Linux to the examples below. For a
-minimal target OS, you may need to disable the built-in allocator in
-src/Makefile and use TARGET_SYS=Other. Don't forget to
-specify the same TARGET_SYS for the install step, too.
+target OS differ, or you'll get assembler or linker errors:
+
+
E.g. if you're compiling on a Windows or OSX host for embedded Linux or Android, you need to add TARGET_SYS=Linux to the examples below.
+
For a minimal target OS, you may need to disable the built-in allocator in src/Makefile and use TARGET_SYS=Other.
+
Don't forget to specify the same TARGET_SYS for the install step, too.
+
-The examples below only show some popular targets — please check
-the comments in src/Makefile for more details.
+Here are some examples where host and target have the same CPU:
# Cross-compile to a 32 bit binary on a multilib x64 OS
@@ -367,82 +353,71 @@ use the canonical toolchain triplets for Linux.
Since there's often no easy way to detect CPU features at runtime, it's
-important to compile with the proper CPU or architecture settings. You
-can specify these when building the toolchain yourself. Or add
--mcpu=... or -march=... to TARGET_CFLAGS. For
-ARM it's important to have the correct -mfloat-abi=... setting,
-too. Otherwise LuaJIT may not run at the full performance of your target
-CPU.
+important to compile with the proper CPU or architecture settings:
+
+
+
The best way to get consistent results is to specify the correct settings when building the toolchain yourself.
+
For a pre-built, generic toolchain add -mcpu=... or -march=... and other necessary flags to TARGET_CFLAGS.
+
For ARM it's important to have the correct -mfloat-abi=... setting, too. Otherwise LuaJIT may not run at the full performance of your target CPU.
+
For MIPS it's important to select a supported ABI (o32 on MIPS32, n64 on MIPS64) and consistently compile your project either with hard-float or soft-float compiler settings.
+
+
+Here are some examples for targets with a different CPU than the host:
# ARM soft-float
make HOST_CC="gcc -m32" CROSS=arm-linux-gnueabi- \
TARGET_CFLAGS="-mfloat-abi=soft"
-# ARM soft-float ABI with VFP (example for Cortex-A8)
+# ARM soft-float ABI with VFP (example for Cortex-A9)
make HOST_CC="gcc -m32" CROSS=arm-linux-gnueabi- \
- TARGET_CFLAGS="-mcpu=cortex-a8 -mfloat-abi=softfp"
+ TARGET_CFLAGS="-mcpu=cortex-a9 -mfloat-abi=softfp"
-# ARM hard-float ABI with VFP (armhf, requires recent toolchain)
+# ARM hard-float ABI with VFP (armhf, most modern toolchains)
make HOST_CC="gcc -m32" CROSS=arm-linux-gnueabihf-
+# ARM64
+make CROSS=aarch64-linux-
+
# PPC
make HOST_CC="gcc -m32" CROSS=powerpc-linux-gnu-
-# PPC/e500v2 (fast interpreter only)
-make HOST_CC="gcc -m32" CROSS=powerpc-e500v2-linux-gnuspe-
-# MIPS big-endian
+# MIPS32 big-endian
make HOST_CC="gcc -m32" CROSS=mips-linux-
-# MIPS little-endian
+# MIPS32 little-endian
make HOST_CC="gcc -m32" CROSS=mipsel-linux-
+
+# MIPS64 big-endian
+make CROSS=mips-linux- TARGET_CFLAGS="-mips64r2 -mabi=64"
+# MIPS64 little-endian
+make CROSS=mipsel-linux- TARGET_CFLAGS="-mips64r2 -mabi=64"
-You can cross-compile for Android using the » Android NDK.
-The environment variables need to match the install locations and the
-desired target platform. E.g. Android 4.0 corresponds to ABI level 14.
-For details check the folder docs in the NDK directory.
-
-
-Only a few common variations for the different CPUs, ABIs and platforms
-are listed. Please use your own judgement for which combination you want
-to build/deploy or which lowest common denominator you want to pick:
+You can cross-compile for Android using the » Android NDK.
+Please adapt the environment variables to match the install locations and the
+desired target platform. E.g. Android 4.1 corresponds to ABI level 16.
-You can cross-compile for iOS 3.0+ (iPhone/iPad) using the » iOS SDK:
+You can cross-compile for iOS 3.0+ (iPhone/iPad) using the » iOS SDK:
Note: the JIT compiler is disabled for iOS, because regular iOS Apps
@@ -452,11 +427,12 @@ much slower than the JIT compiler. Please complain to Apple, not me.
Or use Android. :-p
@@ -513,6 +489,16 @@ the following commands:
cd src
xedkbuild
+
+To cross-compile for Xbox One from a Windows host,
+open a "Visual Studio .NET Command Prompt" (64 bit host compiler),
+cd to the directory where you've unpacked the sources and run
+the following commands:
+
+
+cd src
+xb1build
+
Embedding LuaJIT
@@ -543,14 +529,11 @@ intend to load Lua/C modules at runtime.
If you're building a 64 bit application on OSX which links directly or
-indirectly against LuaJIT, you need to link your main executable
-with these flags:
+indirectly against LuaJIT which is not built for LJ_GC64 mode,
+you need to link your main executable with these flags:
-pagezero_size 10000 -image_base 100000000
-Also, it's recommended to rebase all (self-compiled) shared libraries
-which are loaded at runtime on OSX/x64 (e.g. C extension modules for Lua).
-See: man rebase
Additional hints for initializing LuaJIT using the C API functions:
@@ -636,7 +619,7 @@ to me (the upstream) and not you (the package maintainer), anyway.
Status
@@ -150,7 +151,7 @@ Lua is a powerful, dynamic and light-weight programming language.
It may be embedded or used as a general-purpose, stand-alone language.
Status
@@ -95,12 +96,23 @@ handled correctly. The error may fall through an on-trace
lua_atpanic on x64. This issue will be fixed with the new
garbage collector.
+
+LuaJIT on 64 bit systems provides a limited range of 47 bits for the
+legacy lightuserdata data type.
+This is only relevant on x64 systems which use the negative part of the
+virtual address space in user mode, e.g. Solaris/x64, and on ARM64 systems
+configured with a 48 bit or 52 bit VA.
+Avoid using lightuserdata to hold pointers that may point outside
+of that range, e.g. variables on the stack. In general, avoid this data
+type for new code and replace it with (much more performant) FFI bindings.
+FFI cdata pointers can address the full 64 bit range.
+