OSDev.org

I need somebody to tell how to make c functions cosume less stack memory, how can I avoid that? Links, books are more welcome than quick explanations ;D, thanx...

int means the function will return an integer. this can be canged to void, string, bool...ect. "int Varible1, BOOL Varible 2" these can be aranged/deleted/add on more for the function to get info e.g. "function(34,true);"

int FunctionName(int Varible1, BOOL Varible 2)
{

//---------------Function code goes here----------------\\

return int;
}

Ozguxxx wrote: I need somebody to tell how to make c functions cosume less stack memory, how can I avoid that? Links, books are more welcome than quick explanations ;D, thanx...

Arguments are passed to C functions on the stack, so you write functions that either avoid arguments altogether or write functions that access variables by reference rather than by value.

int foo( struct some_data* data )
{
// mumble
printf( "Foo: %s, Bar: %d\n", data->foobarr1, data->foobar2 );
return OK;
}

instead of:

int foo( int var 1, char var2, long long var 3, __int64 var4 )
{
// using lots of memory for pass by value on stack,
// instead, put all in structure and pass by reference
// on stack, e.g. typically one 32-bit pointer

return something;
}

Hope this answers your question.

Ozguxxx: Would you mind providing a bit more context for the question? If we had an idea of why you were running out of stack space, it might help us find a solution. If the real issue is in your algorithm, or because of a subtle bug that you've missed, then trying to save stack space is not only a premature optimization, but also very likely won't solve real problem.

Scarberry: Uh, OK, but what does this have to do with Ozguxxx's question? I have the feeling this was posted to the wrong thread somehow (yes, it is possible, I've done it myself).

James Buchanan: Very well put, an excellent suggestion. However, it might have helped some of the novice members if you gave an usage example, such as: Otherwise, an excellent reply.

Ok, this passing pointers rathers than variables themselves trick helps... I am trying to optimize the scheduler I am trying to implement, I am trying to make it faster and I dont want it to use huge stack memory because it runs in context of running threads themselves and some special threads might need this memory more than scheduler itself... Do you know a good c programming book telling about these compiler level code optimization stuff?

One other good idea is to reduce the amount of local variables, especially in functions calling other functions, since all those are saved on stack too.

If you need, say char[1024], don't take it from stack, take it from heap instead, and you only need 4 bytes of stack (for the pointer).

Last thing that you should avoid like a plague if you are short of stack are recursive functions since every call takes extra stack space..

lol no it wasnt in the wrong thread but i guess i misread the question. i thought he was asking how to make his own functins lol. i gotta learn to read the whole sentance lol


sorry

ozguxx, in your interrupt handler stubs, you can switch to a dedicated kernel stack prior to invoke the handler after having saved the threads state as well as the *old* esp. I also recommend setting the segment registers to kernel registers.

How do you implement your task switching mechanism?

er... scarberry ... you know that return value isn't found on the stack but rather in eax?

beyond infinity: Im sorry I completly forgot question here, I implement switching by hardware based task switching, very simply by a linked list for now, not trees, no thread-process distinctions for now. I am testing if everything is going alright in the very basic sense. Also I dont have much time to work on os deving these days... Anyway but your idea is cool I mean to set a dedicated stack for serving scheduler. In that way scheduler is protected from messing upand also threads can be protected from overflowing their stacks because of stupidity of os... Ill try it. Again, Im sorry for inconvenience... ;D

Hey well, after trying for 45 minutes to do it, I currently realized that it is impossible to manage this trick in my implementation scheme, well what I am trying to do is just creating a new context for scheduler but I do not want scheduler to be another thread, because it decreases scheduler efficiency a lot. Also since task dispatching takes place in scheduler code how can you manage to get back -I mean swtich back- to your thread again if you separate scheduler and thread's stack? Did you manage this trick? If so how?

I use software taskswitching. a little text about this should be found on my web or at www.osdever.net. and yes, I 've managed to do this trick and it does very well what i want it to do.

Hey, then are you doing task switch to scheduler on every clock tick? how do you make scheduler not run in context of current thread? BTW, I know that this thread is getting far from "General Programming" thingz, but Im sorry, I think it might be good to take this thread to os dev thread.

No, this is no task switch in means of process/thread switching. This is invoking a kernel service with an event (timer tick in this case) and having some actions carried out prior to return to *any* process/thread - be it a driver be it a user process.

It#s the whole secret about multitasking: you use your save-state/restore-state mechanisms which surround the entry points to kernel services (interrupt service routine) for the task switching.

and yes, the scheduling mechanism is carried out in the current process' adress space. the schedulers context is --- the kernel stack. the current process context is dumped in it's kernelspace-stack(esp0) fields.

hope this makes some things clear. I know it takes some nerves to get the knack.

Hey, OK, I was wrong, I managed to run scheduler with a dedicated stack. I think I got what you meant. You mean I must save state of current thread before servicing interrupt so that we do thingz in kernel's context, right? Yes, you are completely right and that is the way things must work. But I am implementing kernel threads for now, I mean I do not have kernel-user distinction for now so I do not use esp0 thingz currently.
Now I am working with any amount of stack (allocated somehwere else which you call "kernel stack" that I need for scheduler), in address space of current thread, as you said. So we are agreeing, right? Thanx for ideas, now some more design problems are waiting for me to solve... ;D

Aye, that's good.