summaryrefslogtreecommitdiff
path: root/doc/status.html
diff options
context:
space:
mode:
Diffstat (limited to 'doc/status.html')
-rw-r--r--doc/status.html64
1 files changed, 33 insertions, 31 deletions
diff --git a/doc/status.html b/doc/status.html
index 3da8fe78..a2de90ab 100644
--- a/doc/status.html
+++ b/doc/status.html
@@ -67,30 +67,31 @@ This is a list of the things you should know about the LuaJIT 2.0 beta test:
67</p> 67</p>
68<ul> 68<ul>
69<li> 69<li>
70The JIT compiler only generates code for CPUs with support for
71<b>SSE2</b> instructions. I.e. you need at least a P4, Core 2/i5/i7
72or K8/K10 to get the full benefit.<br>
73If you run LuaJIT on older CPUs without SSE2 support, the JIT compiler
74is disabled and the VM falls back to the interpreter.
75Run the command line executable without arguments to show the current status
76(<tt>JIT: ON</tt> or <tt>JIT: OFF</tt>).
77</li>
78<li>
79Obviously there will be many <b>bugs</b> in a VM which has been 70Obviously there will be many <b>bugs</b> in a VM which has been
80rewritten from the ground up. Please report your findings together with 71rewritten from the ground up. Please report your findings together with
81the circumstances needed to reproduce the bug. If possible reduce the 72the circumstances needed to reproduce the bug. If possible, reduce the
82problem down to a simple test cases.<br> 73problem down to a simple test case.<br>
83There is no formal bug tracker at the moment. The best place for 74There is no formal bug tracker at the moment. The best place for
84discussion is the 75discussion is the
85<a href="http://www.lua.org/lua-l.html"><span class="ext">&raquo;</span>&nbsp;Lua mailing list</a>. Of course 76<a href="http://www.lua.org/lua-l.html"><span class="ext">&raquo;</span>&nbsp;Lua mailing list</a>. Of course
86you may also send your bug report directly to me, especially when they 77you may also send your bug reports <a href="contact.html">directly to me</a>,
87contains lengthy debug output. Please check the 78especially when they contain lengthy debug output or if you require
88<a href="contact.html">Contact</a> page for details. 79confidentiality.
80</li>
81<li>
82The JIT compiler only generates code for CPUs with support for
83<b>SSE2</b> instructions. I.e. you need at least a P4, Core 2/i3/i5/i7,
84Atom or K8/K10 to get the full benefit.<br>
85If you run LuaJIT on older CPUs without SSE2 support, the JIT compiler
86is disabled and the VM falls back to the LuaJIT interpreter. This is faster
87than the Lua interpreter, but not nearly as fast as the JIT compiler of course.
88Run the command line executable without arguments to show the current status
89(<tt>JIT: ON</tt> or <tt>JIT: OFF</tt>).
89</li> 90</li>
90<li> 91<li>
91The VM is complete in the sense that it <b>should</b> run all Lua code 92The VM is complete in the sense that it <b>should</b> run all Lua code
92just fine. It's considered a serious bug if the VM crashes or produces 93just fine. It's considered a serious bug if the VM crashes or produces
93unexpected results &mdash; please report it. There are only very few 94unexpected results &mdash; please report this. There are only very few
94known incompatibilities with standard Lua: 95known incompatibilities with standard Lua:
95<ul> 96<ul>
96<li> 97<li>
@@ -125,12 +126,12 @@ demonstrable need is shown.
125<li> 126<li>
126The <b>JIT compiler</b> is not complete (yet) and falls back to the 127The <b>JIT compiler</b> is not complete (yet) and falls back to the
127interpreter in some cases. All of this works transparently, so unless 128interpreter in some cases. All of this works transparently, so unless
128you use <tt>-jv</tt>, you'll probably never notice (the interpreter is quite 129you use <tt>-jv</tt>, you'll probably never notice (the interpreter is
129fast, too). Here are the known issues: 130<a href="http://luajit.org/performance.html"><span class="ext">&raquo;</span>&nbsp;quite fast</a>, too). Here are the known issues:
130<ul> 131<ul>
131<li> 132<li>
132Many known issues cause a <b>NYI</b> (not yet implemented) trace abort 133Most known issues cause a <b>NYI</b> (not yet implemented) trace abort
133message. E.g. for calls to vararg functions or many string library 134message. E.g. for calls to some internal library
134functions. Reporting these is only mildly useful, except if you have good 135functions. Reporting these is only mildly useful, except if you have good
135example code that shows the problem. Obviously, reports accompanied with 136example code that shows the problem. Obviously, reports accompanied with
136a patch to fix the issue are more than welcome. But please check back 137a patch to fix the issue are more than welcome. But please check back
@@ -138,7 +139,7 @@ with me, before writing major improvements, to avoid duplication of
138effort. 139effort.
139</li> 140</li>
140<li> 141<li>
141The trace compiler currently does not back off specialization for 142The trace compiler currently doesn't back off specialization for
142function call dispatch. It should really fall back to specializing on 143function call dispatch. It should really fall back to specializing on
143the prototype, not the closure identity. This can lead to the so-called 144the prototype, not the closure identity. This can lead to the so-called
144"trace explosion" problem with <b>closure-heavy programming</b>. The 145"trace explosion" problem with <b>closure-heavy programming</b>. The
@@ -191,20 +192,20 @@ overriding goal for a low-footprint, low-overhead JIT compiler.
191<li> 192<li>
192More <b>optimizations</b> will be added in parallel to the last step on 193More <b>optimizations</b> will be added in parallel to the last step on
193an as-needed basis. Sinking of stores 194an as-needed basis. Sinking of stores
194to aggregates and sinking of allocations are high on the list. Faster 195to aggregates and sinking of allocations are high on the list.
195handling of NEWREF and better alias analysis are desirable, too. More 196More complex optimizations with less pay-off, such as value-range-propagation
196complex optimizations with less pay-off, such as value-range-propagation
197(VRP) will have to wait. 197(VRP) will have to wait.
198</li> 198</li>
199<li> 199<li>
200LuaJIT 2.0 has been designed with <b>portability</b> in mind. 200LuaJIT 2.0 has been designed with <b>portability</b> in mind.
201Nonetheless, it compiles to native code and needs to be adapted to each 201Nonetheless, it compiles to native code and needs to be adapted to each
202architecture. Porting the compiler backend is probably the easier task, 202architecture. The two major work items are porting the the fast interpreter,
203but a key element of its design is the fast interpreter, written in 203which is written in assembler, and porting the compiler backend.
204machine-specific assembler.<br> 204Most other portability issues like endianess or 32 vs. 64&nbsp;bit CPUs
205An x64 port is already available, thanks to the 205have already been taken care of.<br>
206Several ports are already available, thanks to the
206<a href="sponsors.html">LuaJIT sponsorship program</a>. 207<a href="sponsors.html">LuaJIT sponsorship program</a>.
207Other ports will follow &mdash; companies which are 208More ports will follow in the future &mdash; companies which are
208interested in sponsoring a port to a particular architecture, please 209interested in sponsoring a port to a particular architecture, please
209use the given contact address. 210use the given contact address.
210</li> 211</li>
@@ -230,9 +231,10 @@ for efficient <b>vectorization</b>.
230Currently Lua is missing a standard library for access to <b>structured 231Currently Lua is missing a standard library for access to <b>structured
231binary data</b> and <b>arrays/buffers</b> holding low-level data types. 232binary data</b> and <b>arrays/buffers</b> holding low-level data types.
232Allowing calls to arbitrary C functions (<b>FFI</b>) would obviate the 233Allowing calls to arbitrary C functions (<b>FFI</b>) would obviate the
233need to write manual bindings. A variety of extension modules is floating 234need to write manual bindings. A variety of Lua extension modules are
234around, with different scope and capabilities. Alas, none of them has been 235available, with different scope and capabilities. Alas, none of them has been
235designed with a JIT compiler in mind. 236designed with a JIT compiler in mind. An FFI for LuaJIT is currently
237in the design phase, but there's no ETA, yet.
236</li> 238</li>
237</ul> 239</ul>
238<br class="flush"> 240<br class="flush">