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