lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Jan 03, 2002 at 06:17 -0500, Frederic Rudman wrote:
> Concerning your response...
> 
> >Currently, Lua uses the C stack to make its own calls, so yes, the stack
> >used depends on the Lua program being running. On my machine, Lua uses
> >72 "words" (288 bytes) for each function call, so I would say that with
> >only 300 words you wouldn't be able to do much programming...
> 
> Let me rephrase my question to make sure I understand your response. On my
> particular device, there's plenty of accessible heap RAM (in banks of
> 32K-words [i.e. 64K-bytes]); so allocating a "simulated stack" by using
> chunks of heap is no problem (as I seem to see you doing with your lua_state
> variable L).
> 
> What concerns me is not that "simulated execution stack" (of which I can
> allocate as much as needed) but rather what I term the "native" stack which
> is what is used by your interpreter as its running its own internal modules
> (e.g. a hard c-pointer return address for internal c-calls, with their
> locals and all). This would occur inside what I think is your luaV_execute
> function (in file LVM.C);
> 
> In particular, if between any one op code and in between any "call to a lua
> function"  the real native stack simply stays "flat" (regardless of how many
> level of "recursion the lua program itself may be using up) then, for me,
> all is well. Is that a correct assumption on my part?

Only in the latest lua-4.1-work3.  Previous versions implemented Lua
function calls with recursive calls to luaV_execute().  However, the
new code is I think derived from a patch I made for Lua 4.0 which
removes the recursion.  There is still recursion for the case when you
call a C function from Lua, and then that C function calls a Lua
script.  But you can probably just avoid doing that in your app.

The patch is in the "Power Patches" section of www.lua-users.org :

http://lua-users.org/wiki/LuaPowerPatches

Look for "yield patch".

-- 
Thatcher Ulrich <tu@tulrich.com>
http://tulrich.com