Page 1 of 2
Stacks...
Posted: Thu Jan 23, 2003 5:00 pm
by KyleL
I'm a little unclear on some things here about the stack. I think this part is right but I'm not totally sure.
Code: Select all
mov ss, STACK_START
mov sp, STACK_END
This would set stack segment (ss) to the start of the segment. After that is set, the stack pointer (sp) is set to the ending location. The end location would be pointing to the last word in what we would like to be the stack section, that word is what is to be used next.
Thats what I get from reading the source codes I've seen. But from the actual documentation I've been getting an idea more like this:
The stack is the ending location of the stack and stack pointer starts and the begining then counts up and down when things get added and removed from the stack.
Clearly I've got two totally oposite ideas here. Is the stack starting at the end and adding to words of lower value? Or is it starting at the beginning and then added to the end (as suggested by most things) when a new item is added?
I've got another question about the stack as well, at what point should it be setup? Should be be setup in the boot loader? I've seen many that don't but I've got some procedures / jumps in it so I and pretty sure it should be setup.
I'd be better off with some documentation to help fill be in on stacks but I'll settle for what ever I get. If you can help me at all, please do.
Thanks,
Kyle LaDuke
Re:Stacks...
Posted: Thu Jan 23, 2003 5:35 pm
by KyleL
Don't get me wrong here, I've read different things and they all seem to say different stuff. I'm not sure what the heck is right and so I was looking for someone who knows who could tel me a place that is correct.
Re:Stacks...
Posted: Thu Jan 23, 2003 5:51 pm
by Perica
..
Re:Stacks...
Posted: Thu Jan 23, 2003 5:58 pm
by KyleL
Hey, it looks like my idea was right
.. thanks a lot man. I just wasn't sure if I was getting it or not seeing as people kept saying different ways. Thanks a lot.
-Kyle LaDuke
Re:Stacks...
Posted: Fri Jan 24, 2003 12:59 am
by Pype.Clicker
Perica Senjak wrote:
This is a very bad way to do it, you should make multiple selectors that map various area's of memory - you should also make a StackSelector: Then you will avoid Stack Overflows.
You don't avoid it: you'll get notified of it
Now watch out that C expects Stack.base = Data.base so that the address of a variable is independent on whether the variable was static, dynamic(? la malloc) or automatic (on the stack)
The GDT is Capable of holding 255 Descriptors (Not including the Null) - Use the GDT when you can!
Not quite right. the GDT can store up to 8191 descriptorz
Reasonable Size for a Stack??
Posted: Fri Jan 24, 2003 4:40 am
by Perica
..
Re:Stacks...
Posted: Fri Jan 24, 2003 5:09 am
by DarylD
Stack size is a bit of a contentious issue.
For example, my inital kernel stack is just 16Kb. Which is fine because a new stack is created for every new thread from the heap. I haven't approached process stacks yet, but I would probably map 1MB of zero-fill memory for the purpose. But remember it is much easier to control what kernel threads are doing to the stack than unknown user apps.
To be honest, my initial thread 0 turns into an idle thread after initialising sub-systems, so stack size isn't so important.
Daryl.
Re:Stacks...
Posted: Sat Jan 25, 2003 8:58 pm
by Perica
..
Re:Stacks...
Posted: Sun Jan 26, 2003 3:50 am
by Pype.Clicker
usually, the kernel stack don't need to be *that* large... 256Kb of stack should be enough unless you start adding variable-sized arrays or recursive programming ...
Users stack may be larger (because you cannot guess what the user will do), but here you can use virtual memory
Re:Stacks...
Posted: Sun Jan 26, 2003 4:23 am
by Schol-R-LEA
I intend to use rather large stack sizes, but then I have good reason to do so, given my choice of languages.
Re:Stacks...
Posted: Sun Jan 26, 2003 9:29 am
by Tim
Perica Senjak wrote:And my Task's Stacks will be 3kb Each (There will be a 256 task maximum -- Like most OS's ;D)
That's a really small limit (and I don't know of any OS which places an arbitrary limit on the number of tasks). What do you define as a 'task': a process or a thread? It's not uncommon to have hundreds of threads running on a lightly loaded Windows machine, for example.
-- This should take up around 10mb's of memory for stacks, Sounds reasonable ;D
Not to me. Why commit 10MB for stacks all the time? And why do you need a 3MB stack for 'the kernel'? You should need one kernel stack and one user stack per thread (the kernel stack is used in kernel mode).
Also, 3KB is a strange size for anything. Why not use the native page size (4KB)?
Re:Stacks...
Posted: Sun Jan 26, 2003 7:52 pm
by Perica
..
Re:Stacks...
Posted: Mon Jan 27, 2003 1:48 am
by Pype.Clicker
task a generic term without specific meaning, often used to refer IA-32's hardware Task State Segment, but not limited to it. Any context in which some computation can occur.
process: a running program. The process has usually a specific address space in which the program and its libraries are mapped. A process is also a unit of protection: file access, user identification, etc. is done on a process-basis. Most of the control of which component is running on the system is process-related, so that you'll give your user to kill a process, not a task or a thread.
Two distinct process will run independently from each other: they don't see each other and can't modify each other's memory.
thread: an instruction flow plus the resources used to store that flow's state. Every process should have at least one thread, but some may have more (they are then multi-threaded programs).
Threads have a private stack, a private set of CPU registers (usually implemented by storing the registers content in some thread-specific location at task switch), and a private instruction pointer.
Two threads from the same process are running in the same address space, and therefore, what thread A do can do harm to what thread B does. Multithreaded programming usually require more skillz, but it can lead to faster programs because thread switching requires less overhead than process-switching.
Re:Stacks...
Posted: Mon Jan 27, 2003 3:11 am
by Tim
Perica Senjak wrote:Alright, i'll make the Kernel's Stack 512kb
Again, "why do you need a stack for the kernel"? Each thread needs its own stack while in the kernel, so having one centralised kernel stack is redundant.
What i meant by "task" is, i would only allow 256 Programs to be running at once (Although it sounds a bit too much?);
That sounds too few to me, but my point is: why impose a limit at all?
So, what would be a reasonable size for a Task Stack? Or should i start the Stack off small, then Allocate more memory if needed? -- If so, how do i do this?
Yes, you can use paging to reserve the maximum amount of address space (say, 1MB) per thread but only commit, say, 4KB at the start. Then, when a page fault occurs near the end of a stack, you commit and map another 4KB page and continue.
Re:Stacks...
Posted: Mon Jan 27, 2003 3:14 am
by Pype.Clicker
Tim Robinson wrote:
Yes, you can use paging to reserve the maximum amount of address space (say, 1MB) per thread but only commit, say, 4KB at the start. Then, when a page fault occurs near the end of a stack, you commit and map another 4KB page and continue.
Tim, correct me if i'm wrong, but it's not possible to have virtual-expandable stacks in kernel mode, is it ? If so, how the hell could the page fault be received by a stack that needs to be extended ?