Re: No FP compile option for Lua?

[Doug Rogers <rogers@...>]

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