Re: Newbie question about porting

["Frederic Rudman" <frudman@...>]

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?

This also leads to another question: in its execution, can the function
'luaV_execute' be called recursively? Or is any other function called
recursively during the bytecode interpretation of a lua program?

So when you said you needed at least 288 bytes per call, did you mean 288
bytes of that "simulated" lua stack (allocated from heap memory at the start
of the run) or 288 bytes of native stack?

Question 2) Is it fair to say that passing the *L parm everywhere was done
to "insulate" your code from threading and rentrancy issues? If my system
will not allow threading to its users anyway, can I simply remove that as a
parm to the functions and access it as a global in all the functions that
need it?


And about this:
>The next version will have (more or less) fixed use of stack when running
>Lua programs, but there is no schedule for its release...

Are you considering using any volunteers? How much work has been done so
far?

The stack issue above is a showstopper for me. But if I understand correctly
(and the native stack is used only minimally), I would be happy to volunteer
my services to make the code "fixed-stack-usage" compliant if you were
entertaining this anyway, as this would help any embedded software
developpers where this may be an issue.

What do you think?

Sincerely,
Frederic Rudman