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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

John D. Ramsdell-2
For Lua 5.2, please consider adding compile time support for hardware
without floating point instructions.  The patch to enable this support
is in the "Go Long Lua!" section in

http://lua-users.org/wiki/LuaPowerPatches

I tested the patch under 5.1.3, and all is well.

An example of hardware without floating point instructions comes from
Xen.  It provides a very lightweight virtual machine via Mini-OS.
This 32-bit operating system does not save and restore floating point
registers during a context switch, so you cannot use floating point
operations.

John

Reply | Threaded
Open this post in threaded view
|

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

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

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

On 19 Feb 2008 11:09:01 -0500, John D. Ramsdell <[hidden email]> wrote:
> For Lua 5.2, please consider adding compile time support for hardware
> without floating point instructions.  The patch to enable this support
> is in the "Go Long Lua!" section in
>
> http://lua-users.org/wiki/LuaPowerPatches
>
> I tested the patch under 5.1.3, and all is well.
>
> An example of hardware without floating point instructions comes from
> Xen.  It provides a very lightweight virtual machine via Mini-OS.
> This 32-bit operating system does not save and restore floating point
> registers during a context switch, so you cannot use floating point
> operations.
>
> John
>

Reply | Threaded
Open this post in threaded view
|

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

John D. Ramsdell-2
In reply to this post by John D. Ramsdell-2
"Peter Cawley" <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

John D. Ramsdell-2
In reply to this post by John D. Ramsdell-2
> 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.

This isn't what I meant to say.  I meant to say one cannot make the
desired changes given the list of macros you listed.  Furthermore, I
bet an integer only version of Lua would run quite a bit faster on
some number intensive applications.

John

Reply | Threaded
Open this post in threaded view
|

Re: No FP compile option for Lua?

Miles Bader-2
[hidden email] (John D. Ramsdell) writes:
>> Besides, in contrast with my all integer modification, your
>> modification to Lua would run number intensive applications much
>> slower.
>
> This isn't what I meant to say.  I meant to say one cannot make the
> desired changes given the list of macros you listed.  Furthermore, I
> bet an integer only version of Lua would run quite a bit faster on
> some number intensive applications.

I expect it depends on the processor you're talking about.  Floating
point arithmetic on modern processors is often _very_ fast...

-Miles

-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Reply | Threaded
Open this post in threaded view
|

Re: No FP compile option for Lua?

Peter Cawley
When the processor has a floating point unit, yes. When developing on
hardware like the Nintendo DS, there is no hardware floating point in
either the ARM9 or ARM7 chip, so floating point has to be done slowly
in software.

On 20/02/2008, Miles Bader <[hidden email]> wrote:
> [hidden email] (John D. Ramsdell) writes:
>  >> Besides, in contrast with my all integer modification, your
>  >> modification to Lua would run number intensive applications much
>  >> slower.
>  >
>  > This isn't what I meant to say.  I meant to say one cannot make the
>  > desired changes given the list of macros you listed.  Furthermore, I
>  > bet an integer only version of Lua would run quite a bit faster on
>  > some number intensive applications.
>
>  I expect it depends on the processor you're talking about.  Floating
>  point arithmetic on modern processors is often _very_ fast...
>
>  -Miles
>
>
>  --
>  Love is a snowmobile racing across the tundra.  Suddenly it flips over,
>  pinning you underneath.  At night the ice weasels come.  --Nietzsche
>

Reply | Threaded
Open this post in threaded view
|

Re: No FP compile option for Lua?

Doug Rogers-4
In reply to this post by John D. Ramsdell-2
John D. Ramsdell wrote:

> ... The goal is to be able to produce a
> Lua binary that issues no floating 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.

I had similar hurdles porting Lua to PowerQUICC MPC860 boot code a
couple years ago. The OS (LynxOS) provides an FP emulation library, so
it's not a problem at all once the image is loaded.

But for the boot code I wanted to use Lua for my own experiments to test
various low-level hardware options. I also thought it would be nice to
have a uniform language rather than a set of commands that each had to
worry about how they operated (getopt-ish). I wanted to be able to run
loops from the command line without using TeraTerm macros or adding some
sort of 'loop' command - adding control structures to disjoint commands.
For many of us with old command-based interfaces, this is a very
familiar place - a place that embedded Lua can help keep tidy.

I set a bunch of the config options to start, much as described in
previous messages, but there were still floating point exceptions. I
ended up tracking them down in exactly the manner you described, but
with PowerPC assembly listings.

At some point I'd like to create a wiki page with hints for porting Lua
to environments that are constrained in various ways (like DSPs with
16-bit characters - try that!). Like everyone else, it's a matter of
taking the time - in fact, I've already spent too much time on this message.

But for those interested, here are some notes on my particular port:

I found that dlmalloc worked very well for me. See
http://g.oswego.edu/dl/html/malloc.html for an old but still useful
article on it. I mapped all remaining memory into a single morecore() call.

I initially tried hacking up the Lua source to remove variable argument
lists in C because the boot code didn't have a stdarg.h. That turned
into a nasty tar pit so I started over and found that it was easier to
just create an implementation of stdarg by looking at the calling
convention. It would only work up to 12 arguments (and would silently
fail after that). But I haven't had any problems with it.

I could only use the base, table, and string standard libraries. I also
added bitwise operations (glad to hear it's being considered for 5.2,
even if just as a standard package).

I added a few libraries of my own: a 'mem' library for general memory
access (with handy constructs for access to IMMR registers and our PLD),
a 'flash' library for lock/unlock/erase/program, 'set' and 'setenv'
libraries which hold the in-memory or flashed environment variables, and
a library that provides product-specific things such as booting into the OS.

In the end I was able to get all that to work as a proof of concept. It
is still a tad too large. In order to support upgrading from previous
versions, the Lua interface must be reached via a 'lua' command and any
commands used by the upgrading software (long story) must remain
supported. Unfortunately I could not get both to fit in the portion of
flash dedicated to the boot code. Eventually I will take time to play
with it and shrink it enough to fit, then I can merge into the main line.

Hope you found that interesting.

Doug

-- 
Innovative Concepts, Inc. www.innocon.com 703-893-2007 x220