 |
lua-l archive |
|
|
||
|
Thanks for your advice! I will try to implement this kind of layer. Maybe it can be another little opensource project. The information of "newlib, dietlibc" is very useful for me. Bogdan Marinescu wrote:
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