Re: Porting lua to a embeded platform

[Ralph Hempel <rhempel@...>]

Ico Doornekamp wrote:
> * On 2008-05-20 chunlin zhang <zhangchunlin@gmail.com> wrote  :
>
> > Many of the C runtime lib api could not be used in this platform
> > especially "stdio.h",i.e.: malloc/free/realloc printf/fprintf
> > fopen/fread/fwrite/fclose remove/rename/tmpfile(the platform have its
> > own file system api with UTF16 string parameter)
>
> That's a nasty platform you've got there.

Seems like a standard embedded platform to me. :-)

> The other (and IMHO preferred way) would be to leave the Lua source
> (mostly) unmodified, and implement the missing C library functions
> needed to get Lua up and running on a glue layer on top of your
> platform's API.

This is exactly what I did, and it's described in the (hopefully)
soon to be released Lua Gems book.

Leave the Lua source completely alone and do not link in
any standard libraries. The linker will tell you what's missing
and you look for C runtime routines and build your own library
by hand.

It's not that hard, and I used the Minix luibrary source to
do it. You can also use newlib or any standard C runtime source.

What WAS difficult was figuring out a way to do the file related
library on a platform that had no file support at all. It turns
out that you can stub out most of the calls and just implement
getchar() and putchar().

printf() was based on the AVR-lib and is perfectly acceptable since
I use 32 bit ints as the standard Lua number type.

Cheers, Ralph