Thanks for the great replies!
ok... i think i've got it now...
Push just loads from a register to a spot in ram where sp points to. it then decrements sp.
Pop just loads a register from a spot in ram where sp points to. it then increments the sp.
Is this correct?
Yes, and i am thinking about designing another processor (i sort of designed one before; it was an 8 bit processor with no cmp or jump conditionals... (because at the time i didn't know how those were implemented!))
And a few more questions...
How does a stack work for a multi-tasking environment?
If i Push too mutch information for the stack to handle, where is the error thrown?
if i pop too many times (so that i'm trying to make sp<0), does the hardware automatically stop once sp reaches 0, if so how does it do that? if not then how does it send the error to the software (flags register?) and what would happen if two pops were attempted so that sp would be -2 if not corrected? How does it stop the stack corruption which would result if you tried something like:
pop eax
pop ebx
push eax
push ebx
Is that the right way to use push and pop?
Is the stack cached?
Does the stack use the hardware normally used for load and store?
Does the stack keep a "window" of the stack in Cpu memory and the rest in ram?
I'm just full of questions... :-)
Any information, answers to questions or google keywords would be very welcome,
DENC
The stack
Quote:Original post by Nice Coder
How does a stack work for a multi-tasking environment?
For a multitasking environment, there are multiple stacks. The scheduler takes over when it feels like, and swaps out the instruction pointer and the stack pointer so that another process can do stuff.
Quote:If i Push too mutch information for the stack to handle, where is the error thrown?It depends on the architecture and the compiler; there's no easy answer. Most modern architectures will complain, since your program will be writing to memory it doesn't have permission for.
if i pop too many times (so that i'm trying to make sp<0), does the hardware automatically stop once sp reaches 0, if so how does it do that? if not then how does it send the error to the software (flags register?) and what would happen if two pops were attempted so that sp would be -2 if not corrected? How does it stop the stack corruption which would result if you tried something like:
pop eax
pop ebx
push eax
push ebx
Quote:Is the stack cached?The stack is just like any other area of memory, and since it's used so much, the active portion of it will most likely stay in the L1 cache. Some processors may specifically cache the stack separately; I don't know of any offhand.
Does the stack use the hardware normally used for load and store?
Does the stack keep a "window" of the stack in Cpu memory and the rest in ram?
If you really want to learn about call stacks and stack pointers and caching and all that fun stuff, get a good textbook on operating systems. The two subjects are inextricably linked. And you'll learn more about process scheduling than you ever wanted to know (and trust me, process scheduling can be cool).
Author
@Sneftel
If there are multiple stacks, whats to stop too many pop's from moving from one stack to another, or a stack overflow moving to the next stack.
eg.
stack 1 0-1000
stack 2 1000-2000
now say your at the beginning of stack2 (sp = 1000), and you pop the stack. you end up being at the end of stack 1's space. what if by sucessive pushes and pop's, stack 2's sp is smaller then stack 1's sp? then stack 1's stack is corrupt...
How does the os prevent this?
Sneftel, you said that the processor would complain, how would it complain?
things like segmentation faults and other things like that, how are they caught?
If its used so much, then why doesn't it have its own cache? then when trying to do a load/store you can be chacking if its in eather cache in parellel...
Any help would be appriciated,
DENC
If there are multiple stacks, whats to stop too many pop's from moving from one stack to another, or a stack overflow moving to the next stack.
eg.
stack 1 0-1000
stack 2 1000-2000
now say your at the beginning of stack2 (sp = 1000), and you pop the stack. you end up being at the end of stack 1's space. what if by sucessive pushes and pop's, stack 2's sp is smaller then stack 1's sp? then stack 1's stack is corrupt...
How does the os prevent this?
Sneftel, you said that the processor would complain, how would it complain?
things like segmentation faults and other things like that, how are they caught?
If its used so much, then why doesn't it have its own cache? then when trying to do a load/store you can be chacking if its in eather cache in parellel...
Any help would be appriciated,
DENC
Each process has it's own stack. Look into virtual memory, the fundamental concept of 32bit protected mode, on google. In virtual memory, each process has it's own address space, and there is no way (in theory), of overwriting another process's memory.
Author
Isn't virtual memory where the computer uses the hard disk as extra ram when it runs out?
How virtual memory works (found using google)
What does that have to do with protected mode?
"Protected mode aka flat mode, allows you to address all of memory as if it was a huge sequential array" Quoted From here
How does 32 bit protected mode stop me from changing my pointer to acess another programs stack/allocated ram? and what does it have to do with virtual memory?
Can you please explain more clearly what you are trying to say cloudnine?
From Nice coder.
Edit: Clarity
How virtual memory works (found using google)
What does that have to do with protected mode?
"Protected mode aka flat mode, allows you to address all of memory as if it was a huge sequential array" Quoted From here
How does 32 bit protected mode stop me from changing my pointer to acess another programs stack/allocated ram? and what does it have to do with virtual memory?
Can you please explain more clearly what you are trying to say cloudnine?
From Nice coder.
Edit: Clarity
Your notion of "Virtual memory" is wrong. That's not a criticism; most people's is. Here's what it really is.
Virtual memory is a way to give each process its own memory space. Let's say you had a system where programs expect their executable code to be located at the memory location 0x80000000. So when they start, they expect to be able to find executable code there. That's fine.
But what if you have TWO processes?? You can't put them BOTH at 0x80000000, can you? They'd fight to the death! O tempora, o mores!
The solution is, make each one think it's located at 0x80000000. Here's the deal. Between the processor and the memory (physically it is actually inside the CPU these days, but that's not strictly necessary) is something called the Memory Management Unit, or MMU. The MMU keeps track of which process is currently running, and what memory segments it THINKS it has access to. Then it maps those memory segments onto physical memory. So let's say process A has its executable code, which, remember, is located at the virtual address 0x80000000, but its physical address is actually 0x0012a000. When it tries to access location, say, 0x80000004, the MMU says "oookay *wink*" and returns the memory in location 0x0012a004.
Now, let's say that process B gets swapped in. The stack pointer and the instruction pointer are changed. The MMU state is also changed. So now virtual location 0x80000000 points to, say, physical location 0x03002000. Bingo! the two processes will never even see each other.
A few other concepts stem from this. First of all, if the memory segment allocated for the stack is 65536 bytes long, and the process tries to over- or under-run it, there'll be an error, since the location 0x7fffffff doesn't actually exist (i.e. it's not mapped to physical memory). And since there's no way for the program to access physical rather than virtual addresses, functionally there's no way for it to ever affect another process (at least, by overwriting its memory). The idea of swapping to disk stems from all of this, too: the MMU manager might decide to put some data to disk from physical memory, and remove its mapping from the MMU. Then, when the program actually tries to access that virtual memory, the MMU throws an error (because it doesn't have a listing for that virtual address) but the MMU manager intercepts that error, puts the data back from the disk to physical memory, gives the MMU the updated mapping, and tells the MMU to try again. This time, of course, it finds it just fine.
Virtual memory is a way to give each process its own memory space. Let's say you had a system where programs expect their executable code to be located at the memory location 0x80000000. So when they start, they expect to be able to find executable code there. That's fine.
But what if you have TWO processes?? You can't put them BOTH at 0x80000000, can you? They'd fight to the death! O tempora, o mores!
The solution is, make each one think it's located at 0x80000000. Here's the deal. Between the processor and the memory (physically it is actually inside the CPU these days, but that's not strictly necessary) is something called the Memory Management Unit, or MMU. The MMU keeps track of which process is currently running, and what memory segments it THINKS it has access to. Then it maps those memory segments onto physical memory. So let's say process A has its executable code, which, remember, is located at the virtual address 0x80000000, but its physical address is actually 0x0012a000. When it tries to access location, say, 0x80000004, the MMU says "oookay *wink*" and returns the memory in location 0x0012a004.
Now, let's say that process B gets swapped in. The stack pointer and the instruction pointer are changed. The MMU state is also changed. So now virtual location 0x80000000 points to, say, physical location 0x03002000. Bingo! the two processes will never even see each other.
A few other concepts stem from this. First of all, if the memory segment allocated for the stack is 65536 bytes long, and the process tries to over- or under-run it, there'll be an error, since the location 0x7fffffff doesn't actually exist (i.e. it's not mapped to physical memory). And since there's no way for the program to access physical rather than virtual addresses, functionally there's no way for it to ever affect another process (at least, by overwriting its memory). The idea of swapping to disk stems from all of this, too: the MMU manager might decide to put some data to disk from physical memory, and remove its mapping from the MMU. Then, when the program actually tries to access that virtual memory, the MMU throws an error (because it doesn't have a listing for that virtual address) but the MMU manager intercepts that error, puts the data back from the disk to physical memory, gives the MMU the updated mapping, and tells the MMU to try again. This time, of course, it finds it just fine.
my understanding was that virtual memory is using the swap file, which is what your search turned up, and that what you were really looking for [and what Sneftel dsescribed quite well] is virtual address space. Virtual memory and virtual address space are very different things, but like sneftel said, a lot of people get them confused.
Author
Sneftel - Thanks for the information!
i used google and a few keywords from your post and i came across these Two Wiki's
Very interesting!
But another question, how does this work with cacheing?
in a cache line, it reads ahead to help speed up consecutive entries. (at least thats as much as i know about it). with the MMU, when you are trying to read at say 9000 instead of 8FFF, 9000 would have been stored in a cache line. does the MMU stop the request before it gets to the cache?
Thank you for your information,
DENC
i used google and a few keywords from your post and i came across these Two Wiki's
Very interesting!
But another question, how does this work with cacheing?
in a cache line, it reads ahead to help speed up consecutive entries. (at least thats as much as i know about it). with the MMU, when you are trying to read at say 9000 instead of 8FFF, 9000 would have been stored in a cache line. does the MMU stop the request before it gets to the cache?
Thank you for your information,
DENC
Quote:Original post by snk_kid
i wouldn't call stacks data structures, i would say its an abstract data type (ADT) because they can be implementated in number of ways, the concept is beyond a programming language.
As anist points out the stack in the context of hardware still has notion of the concept it just implementated differently
What's the difference between an ADT and a data structure? I see ADT as an obsolete term for data structure.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
