Porting Lua

Lua is the scripting language of choice for World of Warcraft, and I've been reading up on it the last few weeks in my attempts to make a WoW addon.

Today, at work, it struck me that maybe I could port Lua to one of our small, quite specialized Digital Signal Processors that we use for, not very surprisingly I guess, signal processing.

It turned out that I could. Actually, it was so simple that it was almost a disappointment.

This is how I went about:

1. I got the source code from http://www.lua.org/source/5.1/ (there's a .tar linked)
2. I set up a makefile for the code. This was, thanks to our build system already in place, a very small effort. Tbh I didn't pay much attention to the supplied makefile (or any of the other documentation, not even the README file... *cough cough*)
3. I compiled it. It compiled all right. Yes, that's right. It. Compiled. All. Right! The code that I downloaded, about thirty c files or so, all compiled without even a compiler warning. Wow. 
4. I got link problems (1). Turned out that I had missed a couple of c files when writing down the list of source files in my own makefile. (imo, lstrlib, ltablib, and ltable are too close, in some Hammingtonian way, haha)
5. I got link problems (2). Altho our supplier's compiler is mostly ANSI C compliant, the system call for execution of a (string)  is not supported. The call to system() took place in loslib.c. After a deep quite shallow analysis of the problem, I decided to apply the happy go lucky approach and comment out the call. Should it actually bear relevance, it would show sooner or later and I'd have to deal with it then. It would be quite weird, however, I think, for a language with the goal of extreme portability, to rely on being able to do system calls. Probably some obscure area, seldomly visited (note: this belief may be subject to change.... :))
6. I linked the lib with some other OS-ified software of ours, and loaded it to target.
7. I ran it.
8. I got entry point override problems. I thought I had preempted the possibility of Lua's main wreaking havoc with the OS main() (the OS likes to claim main() definition privileges, obviously) by renaming main in lua.c to lua_main.c. (and yes, at the point where the OS hands over to user code, I put a call to lua_main, argc = 1, argv = set by system). However, the first thing that happened at startup was not the familiar printouts of the SW platform, but an error message from the Lua compiler. After a bit of confusion and happiness (the latter derived from getting Lua to run in some form on target) I realized that whereas the interpreter (lua.c) should be included in the build, the compiler (luac.c) should not. They both define a main (some other symbols in common as well).
9. (So apparently) I removed luac.c from the build.
10. I ran it. And OMG!!, through the cable connected to my evaluation board, and through a dialog box on our supplier's IDE running on Windows Vista, and such, in the year of our lord 2010, the Lua interpreter asked for input.
11. I gave input. "print('mumu')" I gave it.
12. "mumu" it answered.

Next up (I guess): Specifying file for Lua on target to read. And make it call some C/C++ functions as specified by script. That'll be cool.