Re: suggestions for new version

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

Re: suggestions for new version

Mark Ian Barlow
N.B: I already made this suggestion to lhf in an earlier private email, but
     I thought it might be worth airing it again here on the list to see if
     there is any other support out there for the idea:

It seems to me (having tried it) that Lua is quite powerful enough to
perform well as an embedded language in another sense; the one where you
use cigarette-packet-sized PCBs and microcontrollers.

Previously this has been the province of Forth and stripped-down dialects of
Basic. Forths are generally the fastest, most compact and the most daunting to
non-technical users. These days you cannot really expect someone who just
bought a hardware widget to write Forth, just because they asked you to make
it fully user-programmable. Basics are, well, *very* basic and usually
incapable of providing the reflexive features you need to do this sort of
thing.

If you *don't* make a short-production-run device fully user-programmable,
and try to anticipate every use it will ever be put to, you are just letting
yourself in for endless support that erodes any profit you managed to
make selling the original device. :-[

I've seen at least one Forth that was as portable as Lua (written in ANSI C)
and it was actually not a lot faster. As RAM prices and their chip footprints
shrink, and microcontrollers get more powerful Lua's many advantages begin
look eminently affordable. Portable byte-code is great for cross-compilation
too; you don't _need_ a cross-compiler!

BUT...

Embedded systems don't generally have file (or even console) I/O. Often
there's just a serial port. You can often get a crippled "libc.lib" for
these systems that provides do-nothing stubs for the I/O functions.

You could eliminate iolib and tell your users they cannot use readfrom() etc.
You could also provide basic console I/O via your serial line, and define
an 'error' fallback that wrote the string to it but you would still need:

>>> A function lua_dochunk(void *) that executed a down-loaded copy of
    luac.out, held somewhere in memory.

As far as I can see this is *all* you would need, provided you are prepared
to fiddle with the linker and maybe write a few missing stubs yourself; a
cost I, at least, would be prepared to accept.

What do you think?
Is there anyone else out there thinking of doing this?
Have you already done it?

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    [hidden email]            Voice / Fax: +44 (0)1207 562 154

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Luiz Henrique de Figueiredo-2
>Embedded systems don't generally have file (or even console) I/O. Often
>there's just a serial port. You can often get a crippled "libc.lib" for
>these systems that provides do-nothing stubs for the I/O functions.
>
>You could eliminate iolib and tell your users they cannot use readfrom() etc.
>You could also provide basic console I/O via your serial line, and define
>an 'error' fallback that wrote the string to it but you would still need:
>
>>>> A function lua_dochunk(void *) that executed a down-loaded copy of
>    luac.out, held somewhere in memory.
>
>As far as I can see this is *all* you would need, provided you are prepared
>to fiddle with the linker and maybe write a few missing stubs yourself; a
>cost I, at least, would be prepared to accept.

I suggest you write a simple stdio replacement that reads from strings.
Something like:

typedef struct {
	char* buffer; /* original string */
	char* current;
	int size;
	...	
} FILE;

int getc(FILE* f)
{
	if (current<(buffer+size)) return *current++
}


etc...

With this replacement, you should be able to use undump.c as is.
Also, you can arrange so that stdin, stdout and stderr act as /dev/null/.
This should be compatible with the rest of the stdio code in Lua.
Now, someone in the world probably has already written such a replacement for
stdio, although it's pretty easy to write too. If you do write it, I'd be
interested.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Mark Ian Barlow
In reply to this post by Mark Ian Barlow
In message <199703171724.OAA27152@server02> lhf writes:

<snip>
 > I suggest you write a simple stdio replacement that reads from strings.
 > Something like:
 > 
 > typedef struct {
 >      char* buffer; /* original string */
 >      char* current;
 >      int size;
 >      ...     
 > } FILE;
 > 
 > int getc(FILE* f)
 > {
 >      if (current<(buffer+size)) return *current++
 > }
 >

Thanks, this is about what I intended to do; it might take me a week
or so to find the time, however...
  
 > With this replacement, you should be able to use undump.c as is.
 > Also, you can arrange so that stdin, stdout and stderr act as /dev/null/.
 > This should be compatible with the rest of the stdio code in Lua.
 > Now, someone in the world probably has already written such a replacement for
 > stdio, although it's pretty easy to write too. If you do write it, I'd be
 > interested.

Me too, anyone care to respond?

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    [hidden email]            Voice / Fax: +44 (0)1207 562 154

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

John Fletcher
In reply to this post by Mark Ian Barlow
> Date:          Mon, 17 Mar 1997 22:51:15 -0300
> Reply-to:      [hidden email]
> From:          [hidden email] (Mark Ian Barlow)
> To:            [hidden email]
> Subject:       Re: suggestions for new version

> 
> Me too, anyone care to respond?
> 
My response is another suggestion.

What about output to a C++ ostream object?

I have some luaL code to create a HTML document in a file declared as 
a C++ output stream.  I can't send lua objects directly to it, but 
have to lua routines with e.g. string arguments which are passed at 
the C++ level to the object.

John
---------------------------------------------------------------------
Dr John P. Fletcher          Tel: (44) 121 359 3611 ext 4625
Department of Chemical Engineering and Applied Chemistry (CEAC),
Aston University,            Fax: (44) 121 359 4094
Aston Triangle,              Email: [hidden email]
BIRMINGHAM B4 7ET  U.K.   
---------------------------------------------------------------------
CEAC Web site http://www.ceac.aston.ac.uk/
---------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Mark Ian Barlow
In message <199703180948.GAA00562@...> [hidden email] writes:

<snip>
 > What about output to a C++ ostream object?
 > 
 > I have some luaL code to create a HTML document in a file declared as 
 > a C++ output stream.  I can't send lua objects directly to it, but 
 > have to lua routines with e.g. string arguments which are passed at 
 > the C++ level to the object.
 > 
 > John

Probably more elegant, but requires a C++ cross-compiler for the target, or
manual use of Cfront on the host. C++ compilers for popular chips *are*
becoming more available, but there's a lot of people in comp.arch.embedded
complianing about astronomical prices at the moment...

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    [hidden email]            Voice / Fax: +44 (0)1207 562 154

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

John Fletcher
In reply to this post by John Fletcher
> Date:          Tue, 18 Mar 1997 13:18:05 -0300
> Reply-to:      [hidden email]
> From:          [hidden email] (Mark Ian Barlow)
> To:            [hidden email]
> Subject:       Re: suggestions for new version

> In message <199703180948.GAA00562@...> [hidden email] writes:
> 
> <snip>
>  > What about output to a C++ ostream object?
>  > 
>  > I have some luaL code to create a HTML document in a file declared as 
>  > a C++ output stream.  I can't send lua objects directly to it, but 
>  > have to lua routines with e.g. string arguments which are passed at 
>  > the C++ level to the object.
>  > 
>  > John
> 
> Probably more elegant, but requires a C++ cross-compiler for the target, or
> manual use of Cfront on the host. C++ compilers for popular chips *are*
> becoming more available, but there's a lot of people in comp.arch.embedded
> complianing about astronomical prices at the moment...
> 
I didn't mean necessarily in your situation, but in general.

John
---------------------------------------------------------------------
Dr John P. Fletcher          Tel: (44) 121 359 3611 ext 4625
Department of Chemical Engineering and Applied Chemistry (CEAC),
Aston University,            Fax: (44) 121 359 4094
Aston Triangle,              Email: [hidden email]
BIRMINGHAM B4 7ET  U.K.   
---------------------------------------------------------------------
CEAC Web site http://www.ceac.aston.ac.uk/
---------------------------------------------------------------------