[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Porting lua to a embeded platform
- From: Chunlin Zhang <zhangchunlin@...>
- Date: Tue, 20 May 2008 17:01:14 +0800
Ico Doornekamp wrote:
Yes.It is not a open platform.Porting lua is my effort to improve its
* On 2008-05-20 chunlin zhang <email@example.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.
I spent 1 night to compile lua into the platform. And spent 2 day to
run "hello world"(using luaL_dostring) in the PC emulator. Spent 3
day to run "hello world" in mobile phone,because found that I should
get rid of the C runtime api not support in the platform.
And now I want to run lua script from file(using luaL_dofile),and
found that I should rewrite luaL_loadfile and so on with platform
utf16 string file system api.I think I will spend more days...
Have anyone else ever done this kind of porting?Or any advice to me...
I think there are generally two ways of porting Lua to a platform like
yours: one is to just start compiling, find where the build breaks, and
modify the Lua code to use your platform-specific API instead of the
standard C library functions. This is a lot of work, and in the end
leaves you with a severely modified Lua implementation, which will not
make future updates any easier.
Any code using the C runtime lib api can be compile in this platform.But
i.e. the call of "malloc/free" make the mobile phone can not boot
normally,and I don't know why exactly.So I get rid of all the code cause
the linking of "malloc/free"(i.e. printf ...).There may be more api can
not use other than "malloc/free",I even write a tool to analyze which
exactly more functions are linking then the version have not lua source.
I simply delete the code call those runtime api now().And replace some
with my implement version(i.e. printf).So I am using your first method.
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. Most of these C library functions aren't too hard to
build on top of another filesystem (fopen/fread/fwrite, etc), and for
the harder functions like [vs]printf() you might get away with
implementing only a stub or part of the functionality.
What method did you use for your Lua port ?