[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: about the new version
- From: Roberto Ierusalimschy <roberto@...>
- Date: Fri, 07 Apr 2000 15:34:38 -0300
We will soon (by Easter?) release a new (alpha) version of Lua.
The big change is that Lua now is completely reentrant. The state is
passed around as an extra parameter, so that there are no global variables
in the code. (There is a mechanism with #defines that should ensure that
old code compiles without changes.)
To make that change, we have to touch the whole code; therefore, we took
the opportunity to improve some algorithms, and to remove some "bad"
features. In the end, the new version is more than 20% faster than Lua 3.2,
often much more than that. (E.g., the life program, from Dave Bollinger,
runs in less than 50% of the previous time).
The other main changes are listed below:
- in a call like f(g(x)), all results from `g' are passed to `f', when `f'
is the last/only argument. (This may result in incompatibilities; for
instance, "write(gsub(...))" will write an extra number, which is the
second result from gsub. You may correct this case with
"write(gsub(...), '')", or "local g=gsub(...); write(g)".)
- there is a new control structure "break", and "repeat" may finish with
"end" for infinite loops. For instance
line = read()
if line==nil then break end
local n,v = nil
n,v = next(t, n)
if not n then break end
Also, statements can have labels. A break without a label finishes the
inner loop (while/repeat), and a break with a label breaks the
corresponding statement. (This is similar to breaks in Ada and Java.)
- the code now uses "const" consistently. Among other things, that makes it
clear that the only global names in the C code are "const", and makes the
API more precise. (This will also generate some warnings in old code,
because lua_getstring now returns a "const char *").
- the code now is "pure C": ANSI C *and* C++. So you can compile Lua as a
C++ program without errors or warnings. (With our compiler [gcc 18.104.22.168],
this results in a much bigger and a little slower program; but you have the
- the structures of opcodes changed. Instead of a byte-oriented stream of
byte-codes, with each instruction taking a variable number of bytes, now
the opcode is an array of longs (4 bytes), with each instruction using one
position. (You can change that to 2-byte instructions, using smaller limits
for maximum number of local variables, etc.) That makes code generation
more straightforward, allows peep-hole optimizations (for instance, i=i+1
codes as one single instruction), and facilitates the implementation of new
control structures. Also, now Lua uses real "jump code" for conditionals.
- the hash algorithm for tables was rewritten. The new algorithm is faster
than the old one, uses less memory, and is more stable (that is, bad
cases are rarer).
- we removed the garbage collection tag method for tables. That was a
source of problems, because when there was no more references to a table we
had to create one for the tag method. Garbage collection should be
invisible from Lua. Now there is only GC tag methods for userdata (C data),
and only C code can set them. (That is, GC tag methods concerns only C code.)
- we removed "read patterns" from the "read" function. Nobody (or very few
people) used them, and they were very inefficient. Now the only options are
"*a" (read the whole file), "*l" (read a line, the default), "*n" (read a
number), and "*w" (read a word). These options were already present in
Lua3.2, but now they are much faster. (The old read patterns can still be
enabled with a #define).
- the optimizations during code generation can change tests such as "a<b"
(e.g., "if a<b then..." will generate "jump if a>=b"). Therefore, there is
no point in having four different tag methods for comparisons, when we
cannot know which one will be used. Now, there is only one tag method for
comparison ("lt", less than). Other tests use this tag method following the
usual rules: a>b === b<a; a<=b === not (b<a); b<=a === not (a<b).
- the whole debug API was rewritten. The old API used too many pointers to
variables, and has too many special cases and codes. It should be easy to
change programs to this new API, and we will provide an "adaptor" that
simulates the old API using the new one.
- the nil in next/nextvar is optional ;-)