Re: Porting lua to a embeded platform

["Bogdan Marinescu" <bogdan.marinescu@...>]

Well, you offered the details yourself :)

>>>> 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)

Take each of the routines you're having problems with, find out their
standard interface (generally it's enough to do a google search for
"linux man <functionname>" to find out the interface) and implement
them in a separate library. For the file operations you could probably
map between the POSIX calls and your embedde platform calls easily
(since a filesystem is already in place). For malloc/free/realloc
things can be a bit more problematic. If all fails, you could use a
different allocator (for example dlmalloc, search google for details)
with Lua (by giving it a fixed memory region that you'd get from your
default allocator, or simply a physical address and a length, whatever
suits you best). For printfs there are a number of freeware libraries
that implement only the printf functions and nothing else (the first
example that comes to mind is "trio").
I'm not saying this is easy. Most likely it will be a difficult
process, this is why I said that you should implement a "minimal
porting layer" - implement as much as you need to run Lua and you
should be fine. It also won't hurt to look at some free LIBC
implementation (newlib, dietlibc) maybe you could use parts of them or
even the complete package in your application. Even with all this
complexity in mind, I'd still go with the porting layer way (as
opposed to modifying Lua itself).

HTH,
Bogdan

On Tue, May 20, 2008 at 12:10 PM, Chunlin Zhang <zhangchunlin@gmail.com> wrote:
> Bogdan Marinescu wrote:
>>
>> I'd go with a minimal "ANSI porting layer" for your embedded platform.
>> This way you won't have to modify Lua itself, you'll be able to easily
>> apply patches and upgrade to new versions without problems.
>
> That's great!Can you offer more detail of this minimal layer?
> Thanks!
>>
>> On Tue, May 20, 2008 at 10:26 AM, Ico Doornekamp <lua@zevv.nl> 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.
>>>
>>>> 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.
>>>
>>> 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 ?
>>>
>>> --
>>> :wq
>>> ^X^Cy^K^X^C^C^C^C
>>>
>>>
>>
>
>