Re: No FP compile option for Lua? [was: upcoming changes in Lua 5.2]

[ramsdell@... (John D. Ramsdell)]

"Peter Cawley" <lua@corsix.org> writes:

> How are the following configuration options not sufficient in this
> area?

Peter,

I conclude from your post that I failed to clearly explain the goal of
a no FP compile option for Lua.  The goal is to be able to produce a
Lua binary that issues no floating instructions.  Let me tell you how
I assured that after modifying Lua 5.1 with my "Go Long Lua!" patch,
the resulting binary issues no floating point instructions.  I
produced an assembly language listing of each source file in the src
directory, and grep'ed for strings that matched x86 floating point
instruction names.

By searching for floating point instruction names, you find
unexpected items that require patching.  For example, you must modify
the os library so that in no longer adds a definition for "difftime".
You have to chuck the math package.  You have to modify the string
library so that %e, %E, %f, %g, and %G string formats are no longer
recognized.  But the biggest changes involve arithmetic.  

To support integer only arithmetic, there are two issues you must
address.  To handle division by zero, you must define two macros for
both division and modulus.  One pair of macros is used in src/lvm.c,
where they perform their operations in the context of variable L, and
therefore can report divide and modulo by zero errors with
luaG_runerror.  The other pair do not check for zero, and are used
everywhere else.

The second issue is defining integer versions of division, modulus, and
exponentiation.  Implementations of division and modulus must take
into account all of the allowed ways to implement C's % operator.

So let me summarize.

> How are the following configuration options not sufficient in this
> area?

The modifications you suggest do not have the desired effect of
generated a Lua binary without floating point instructions.  Besides,
in contrast with my all integer modification, your modification to Lua
would run number intensive applications much slower.

> #define LUA_NUMBER_DOUBLE
> #define LUA_NUMBER	double
> #define LUAI_UACNUMBER	double
> #define LUA_NUMBER_SCAN		"%lf"
> #define LUA_NUMBER_FMT		"%.14g"
> #define lua_number2str(s,n)	sprintf((s), LUA_NUMBER_FMT, (n))
> #define LUAI_MAXNUMBER2STR	32 /* 16 digits, sign, point, and \0 */
> #define lua_str2number(s,p)	strtod((s), (p))
> #define luai_numadd(a,b)	((a)+(b))
> #define luai_numsub(a,b)	((a)-(b))
> #define luai_nummul(a,b)	((a)*(b))
> #define luai_numdiv(a,b)	((a)/(b))
> #define luai_nummod(a,b)	((a) - floor((a)/(b))*(b))
> #define luai_numpow(a,b)	(pow(a,b))
> #define luai_numunm(a)		(-(a))
> #define luai_numeq(a,b)		((a)==(b))
> #define luai_numlt(a,b)		((a)<(b))
> #define luai_numle(a,b)		((a)<=(b))
> #define luai_numisnan(a)	(!luai_numeq((a), (a)))
> #define lua_number2int(i,d)	((i)=(int)(d))
> #define lua_number2integer(i,d)	((i)=(lua_Integer)(d))

John