Embedded Lua

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Embedded Lua

D Burgess-4
Please, can all of the embedded users of Lua help me with some
magic one liners of why they think Lua is so good for embedded
systems?

Thanks in advance

David B.
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Adam D. Moss
D Burgess wrote:
> Please, can all of the embedded users of Lua help me with some
> magic one liners of why they think Lua is so good for embedded
> systems?

On top of all of the great reason why Lua is good non-embedded,
it has a straightforward license for embedding, no dependancies,
unobtrusive API, a small binary footprint, and pretty
readable/moddable source.

--adam
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Luiz Henrique de Figueiredo
Also, the Lua core depends lightly on the ANSI C runtime library.
Besides some simple functions from string.h and ctype.h, it needs
sprintf and strtod to convert doubles to and from text, and setjmp,
longjmp and exit. Lua 5.1 also needs pow, floor, and localeconv.
The Lua libraries depend more heavily on the C standard library.

Another feature that is nice for embedded applications that have
limited memory is that the larger parts of the core (lexer, parser,
and code generator) can be very easily removed, and still leave a fully
functional core, which of course can only run precompiled programs.
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Ralph Hempel
In reply to this post by Adam D. Moss
> D Burgess wrote:
>> Please, can all of the embedded users of Lua help me with some
>> magic one liners of why they think Lua is so good for embedded
>> systems?
>
> On top of all of the great reason why Lua is good non-embedded,
> it has a straightforward license for embedding, no dependancies,
> unobtrusive API, a small binary footprint, and pretty
> readable/moddable source.

I can second that. I'm using Lua in a small embedded app
and I got rid of newlib and its relative bloat.

I pulled together a very lightweight C runtime and was able
to integrate it with Lua fairly easily. A couple of tweaks
in luaconf.h and I was up and running.

I have to say the source code is very easy to read and also
very clean. It compiles with no warnings and is a pleasure to
explore.

I plan to add Lua as a scripting interface whenever possible.

I used to use Forth for embedded app interfaces, and for very
memory constrained systems, I still do.

But Lua just "feels" like the right thing to do.

Cheers, Ralph

Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Lisa Parratt
In reply to this post by Luiz Henrique de Figueiredo

On 30 Mar 2006, at 23:46, Luiz Henrique de Figueiredo wrote:

> Also, the Lua core depends lightly on the ANSI C runtime library.
> Besides some simple functions from string.h and ctype.h, it needs
> sprintf and strtod to convert doubles to and from text, and setjmp,
> longjmp and exit. Lua 5.1 also needs pow, floor, and localeconv.
> The Lua libraries depend more heavily on the C standard library.

I don't see this as an advantage. The first thing I have to do with a  
new Lua release is patch in an abstraction layer so that these may be  
easily replaced. Personally I'd like to see every "standard" function  
call given a prefix and a default header file of #defines that maps  
them to their nonprefixed equivalents.

Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

David Jones-2

On Mar 31, 2006, at 07:15, Lisa Parratt wrote:

>
> On 30 Mar 2006, at 23:46, Luiz Henrique de Figueiredo wrote:
>
>> Also, the Lua core depends lightly on the ANSI C runtime library.
>> Besides some simple functions from string.h and ctype.h, it needs
>> sprintf and strtod to convert doubles to and from text, and setjmp,
>> longjmp and exit. Lua 5.1 also needs pow, floor, and localeconv.
>> The Lua libraries depend more heavily on the C standard library.
>
> I don't see this as an advantage. The first thing I have to do with a
> new Lua release is patch in an abstraction layer so that these may be
> easily replaced. Personally I'd like to see every "standard" function
> call given a prefix and a default header file of #defines that maps
> them to their nonprefixed equivalents.

Why can't you just provide replacements for the C standard library
facilities that have the same names as the functions from the C
standard library?

David Jones

Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Lisa Parratt
David Jones wrote:

>
> On Mar 31, 2006, at 07:15, Lisa Parratt wrote:
>
>>
>> On 30 Mar 2006, at 23:46, Luiz Henrique de Figueiredo wrote:
>>
>>> Also, the Lua core depends lightly on the ANSI C runtime library.
>>> Besides some simple functions from string.h and ctype.h, it needs
>>> sprintf and strtod to convert doubles to and from text, and setjmp,
>>> longjmp and exit. Lua 5.1 also needs pow, floor, and localeconv.
>>> The Lua libraries depend more heavily on the C standard library.
>>
>> I don't see this as an advantage. The first thing I have to do with a
>> new Lua release is patch in an abstraction layer so that these may be
>> easily replaced. Personally I'd like to see every "standard" function
>> call given a prefix and a default header file of #defines that maps
>> them to their nonprefixed equivalents.
>
> Why can't you just provide replacements for the C standard library
> facilities that have the same names as the functions from the C standard
> library?

Because the functions are provided by the C library, they're just
buggy/incomplete/inadequate for purposes/incompatible with
configuration. In the real world, projects are written by multiple
people. I can't wholesale replace standard functions, despite their
flaws - other people may and probably will have written code that
depends on those flaws. Yes I could raise I bug on them, but when the
product's late already it makes it look like my problem, and therefore
as far as the company's concerned - *Lua*s problem.

"pow" is in fact an example of where Lua does it *right* - it doesn't
call "pow", it calls "luai_numpow". The platforms I regularly work on
have no floating point, and emulate it if you try and use math
functions. Lua is configured to use integers. I obviously don't want to
be calling "pow", so  a quick modification to the configuration, and it
now calls "intPow". This uses integer partial products to perform the
exponentiation, and gives me far better performance.

I'm not saying Lua should be rendered difficult to integrate. It's just
it should be made fully independent, but provided with default bindings
that are useful in the most common case, exactly as is the case with
luai_numpow.

--
Lisa
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Luiz Henrique de Figueiredo
> I'm not saying Lua should be rendered difficult to integrate. It's just
> it should be made fully independent, but provided with default bindings
> that are useful in the most common case, exactly as is the case with
> luai_numpow.

Can't you add definitions in luaconf.h for that? Like this:
#define exit myexit

--lhf
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Lisa Parratt
Luiz Henrique de Figueiredo wrote:
> Can't you add definitions in luaconf.h for that? Like this:
> #define exit myexit

Libraries that interface with Lua frequently require luaconf.h to be
included so that the same types are used across all Lua interfaces. This
would mean that the #defined functions would also be propagated to these
libraries, which is not necessarily desirable, and could verge on the
dangerous.

--
Lisa
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

Roberto Ierusalimschy
> >Can't you add definitions in luaconf.h for that? Like this:
> >#define exit myexit
>
> Libraries that interface with Lua frequently require luaconf.h to be
> included so that the same types are used across all Lua interfaces. This
> would mean that the #defined functions would also be propagated to these
> libraries, which is not necessarily desirable, and could verge on the
> dangerous.

You can protect those definitions with LUA_CORE:

  #if defined(LUA_CORE)
  #define exit myexit

It may be a good idea to have proper names for standard functions
used by the core, not for the easiness of redefinition, but for
documentation of the core dependencies.  But it also may create too much
bureaucracy.

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Embedded Lua

D Burgess-4
 Roberto Ierusalimschy  wrote:
> It may be a good idea to have proper names for standard functions
> used by the core, not for the easiness of redefinition, but for
> documentation of the core dependencies.

I dont see the problem. The linker documents the dependencies.
Reply | Threaded
Open this post in threaded view
|

RE: Embedded Lua

Nijdam
In reply to this post by D Burgess-4
And on some systems the "standard" definitions don't even exist. As part
of our port to BREW we actually went through and renamed the standard
dependencies so that we could easily identify them as part of the
porting of Lua to various platforms. Made life a lot easier for the
embedded side and the default definitions for the more standard
environments was very straightforward.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of D Burgess
Sent: Friday, March 31, 2006 12:42 PM
To: Lua list
Subject: Re: Embedded Lua

 Roberto Ierusalimschy  wrote:
> It may be a good idea to have proper names for standard functions
> used by the core, not for the easiness of redefinition, but for
> documentation of the core dependencies.

I dont see the problem. The linker documents the dependencies.