Improved API and code generation

["Timm S. Mueller" <tmueller@...>]

Hi,

I'm currently adapting my projects to Lua 5.1. Here are some
suggestions that may help to enhance Lua's efficiency when compiled
for certain environments.

* Functions that are neither part of Lua's API nor local to a source
could receive a markup named LUA_LOCAL, e.g.

src/lfunc.c:
LUA_LOCAL Closure *luaF_newCclosure(lua_State *L, ...

src/luaconf.h:
#ifndef LUA_LOCAL
#define LUA_LOCAL
#endif

etc/all.c:
#define LUA_LOCAL static
#include "lapi.c"
...

When building from a single source, this could be used to hint the
compiler to perform whatever it considers appropriate for inlining
and unrolling. It also helps to avoid pollution of the resulting libs
and DLLs with unneeded symbols.

* The second suggestion is related to cases when someone might have
to deal with different ABIs. If you wish to provide a binary DLL of
Lua on your weirdo platform or embedded system, and this DLL aims to
be conforming to the platform's general ABI (which may be stack-based),
but you choose to build Lua with register arguments (so as to wrench
some extra cycles from your code), then you would need an extra markup
for passing function arguments that the implementor can qualify with
compiler-specific definitions (like "__stdargs"), e.g.:

src/luaconf.h:
#ifndef LUA_CALLBACK
#define LUA_CALLBACK
#endif

src/lua.h:
typedef LUA_CALLBACK int (*lua_Chunkwriter)(lua_State *L, ...

All callbacks that could possibly cross the API (and therefore ABI)
barrier (i.e. between application and DLL) would have to be treated
that way. This addition may be stretching it a bit far, but I
consider this a good measure for making an API entirely robust. 

- Timm