Re: kernel stack challenge

[Helge Hafting <helgehaf@aitel.hist.no>]

On Mon, Apr 05, 2004 at 10:05:37AM -0700, Sergiy Lozovsky wrote:
> > Consider rewriting your function to use allocated
> > memory instead of stack, this isn't all that hard.
> 
> I put LISP interpreter inside the Kernel -
> http://vxe.quercitron.com
> 
> It works, but it use a lot of stack memory. It's
> impossible to rewrite it easily, though I'll
> investigate why exactly it uses so much of stack
> memory (though it's nature of LISP). There are no
> serious kernel memory allocation (as of my interpreter
> code review, only function calls; recursions in LISP
> application itself are eliminated for sure), but I'll
> trace stack usage more thouroughly.
> 
Consider this.  We're currently experimenting with a
transition from 8k to 4k stacks on x86, and that is
considered a very good thing.  Allocating a single-
page stack is easy, two (contigous) pages might fail.

So a bigger kernel stack is out.

As for rewriting code so it doesn't use stack - it
_is_ easy, but it might be a lot of _work_.

The simple approach is to replace all (big) stack
allocations with an explicit stack structure that you manages
on the heap. There'll be more code, but it won't be slower
because all the extra code is stuff that happen automatically
with the hw stack. (I.e. stuff the compiler normally take
care of.)

There is some more work if your interpreter also does deep recursion.
It involves making one big function of those that do the recursion
and manage the "calls" yourself with an array and a switch statement.
Again, not particularly hard, but it could take some time to implement.

Helge Hafting