number question

["Ralf HECKHAUSEN" <RHeckhau@...>]

We want to run Lua on an machine without floating-point-unit and basically only need integer numbers. How much effort is it to switch the number type to long instead of double? Is it possible to have a new user type float next to number with all standard operators? Did someone already implement this?
Thanks,
Ralf Heckhausen

>>> roberto@inf.puc-rio.br 04/07/00 08:35pm >>>
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 

  local line
  repeat
    line = read()
    if line==nil then break end
    ...
  end 

  local n,v = nil
  repeat
     n,v = next(t, n)
    if not n then break end
    ...
  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 2.7.2.3], 
this results in a much bigger and a little slower program; but you have the 
choice). 

- 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 ;-) 


-- Roberto