OSDev.org

iansjack wrote:But I'm afraid that you may be overestimating your current level of knowledge. A stack is a very basic concept in computer programming and almost every modern processor makes use of one. This is not simply a question of learning a particular processor's assembly language and instruction set but is a fundamental concept that applies to almost every computer. You will also need to be familiar with other concepts, such as C structures, function calling conventions (ABIs), linked lists, binary trees, how peripheral devices are addressed, etc., etc.

I've known how the stack works for a long time. I just don't know how the registers are organized.

OK. I know when my advice isn't wanted. I'll leave you to it.

But try to solve your own problems rather than posting every one here. Believe me, you will learn a lot more that way. (Final bit of advice for you to ignore.)

iansjack wrote:OK. I know when my advice isn't wanted. I'll leave you to it.

Why do you think that?
I follow your advice and read about the processor and assembly language.

iansjack wrote:But try to solve your own problems rather than posting every one here. Believe me, you will learn a lot more that way. (Final bit of advice for you to ignore.)

Ok, I will try not to run first to the forum, I will try to solve them myself.
Thanks.

No worries, @iansjack can be harsh sometimes, but he is not wrong (he is usually right about things). Single-stepping will teach you a lot, and it will show you how the theory is implemented in practice, how the ESP register stores the stack, what values are stored in there etc. This is a really good advice, I would take it if I were you.

He is also right about not asking questions all the time: learning how to learn is a very important part of OS development. This does not mean you shouldn't ask when you're stuck, but think of it as the last resort when everything else had failed you.

And concerning to your question about setting the stack in a bootloader: it is easy because then the stack is empty. When it is empty, you can freely move it around because there's no code that relies on values in it. In a middle of a C function the stack is not empty (it is full of the callback trace, return addresses and stack frame pointers), there you must be careful if you want to relocate the stack. Software context switching can be implemented using this: you push the full environment onto the stack (all registers, etc.), you switch to the new task's stack, and upon return, the function pops the environment for the new task. The values will be different, but the layout of the stack must be the same, it must contain exactly as many values on pop as it was pushed before the stack-switch, otherwise your code will misbehave. Hope this makes sense to you.

Cheers,
bzt

bzt wrote:No worries, @iansjack can be harsh sometimes, but he is not wrong (he is usually right about things). Single-stepping will teach you a lot, and it will show you how the theory is implemented in practice, how the ESP register stores the stack, what values are stored in there etc. This is a really good advice, I would take it if I were you.

He is also right about not asking questions all the time: learning how to learn is a very important part of OS development. This does not mean you shouldn't ask when you're stuck, but think of it as the last resort when everything else had failed you.

And concerning to your question about setting the stack in a bootloader: it is easy because then the stack is empty. When it is empty, you can freely move it around because there's no code that relies on values in it. In a middle of a C function the stack is not empty (it is full of the callback trace, return addresses and stack frame pointers), there you must be careful if you want to relocate the stack. Software context switching can be implemented using this: you push the full environment onto the stack (all registers, etc.), you switch to the new task's stack, and upon return, the function pops the environment for the new task. The values will be different, but the layout of the stack must be the same, it must contain exactly as many values on pop as it was pushed before the stack-switch, otherwise your code will misbehave. Hope this makes sense to you.

Cheers,
bzt

Yes, I understand.
I will study this issue better.
Thanks for the answer.

Even if this gets ignored, I might as well give it anyway, as some references. I'd strongly (very, very strongly) encourage you to read The Morgan Kaufmann Series in Computer Architecture and Design, specifically Computer Organization and Design: the Hardware-Software Interface, either the MIPS or RISC-V editions. They may have typos in them, but they describe all the concepts you appear to be missing in regards to the stack and the stack pointer. (And yes, I'd encourage you to read it all -- you might find it very informative. And, as always, practice, practice, practice.) However, as others here have mentioned, that's not all your missing. Pick up a book (or two, or three) on data structures and algorithms. Seriously. That'll especially come in handy when you go and start implementing complex data structures like BTrees for file systems.

Ethin wrote:Even if this gets ignored, I might as well give it anyway, as some references. I'd strongly (very, very strongly) encourage you to read The Morgan Kaufmann Series in Computer Architecture and Design, specifically Computer Organization and Design: the Hardware-Software Interface, either the MIPS or RISC-V editions. They may have typos in them, but they describe all the concepts you appear to be missing in regards to the stack and the stack pointer. (And yes, I'd encourage you to read it all -- you might find it very informative. And, as always, practice, practice, practice.) However, as others here have mentioned, that's not all your missing. Pick up a book (or two, or three) on data structures and algorithms. Seriously. That'll especially come in handy when you go and start implementing complex data structures like BTrees for file systems.

Thank you for advice. I will read these books, and I am sure they will do me good.

mrjbom wrote:

iansjack wrote:But I'm afraid that you may be overestimating your current level of knowledge. A stack is a very basic concept in computer programming and almost every modern processor makes use of one. This is not simply a question of learning a particular processor's assembly language and instruction set but is a fundamental concept that applies to almost every computer. You will also need to be familiar with other concepts, such as C structures, function calling conventions (ABIs), linked lists, binary trees, how peripheral devices are addressed, etc., etc.

I've known how the stack works for a long time. I just don't know how the registers are organized.

The big problem is that the point you are misunderstanding about how the stack register works is basically the same across every CPU architecture that has a stack, so you effectively don't know how the stack works. You seem to think that the stack pointer points to the base of the stack, but in reality, it always points to the most recent item pushed. This means that the stack pointer changes on every push or pop, on every call or return, and any time a stack frame is created or abandoned.

Also, you seem to have (or have had) the impression that changing the stack pointer causes all the data on the stack to move, but this is not the case. Any time you move the stack, you first have to copy the whole stack, then change the stack pointer to point to the same data in the new stack as it's pointing to in the old one, unless A) the function that switches to the new stack does not use any stack variables, and B) the function that switches to the new stack does not return, or, at least, does not return without switching back to the original stack.

linguofreak wrote:Any time you move the stack, you first have to copy the whole stack, then change the stack pointer to point to the same data in the new stack as it's pointing to in the old one,

The C ABI doesn't allow the stack to move: there may be pointers (in the stack or elsewhere) that refer to data in the stack, and you can't know where these pointers are in order to update them.

You can't use inline assembly to manipulate the stack pointer either, since the compiler assumes you won't change it. If you need to mess with the stack pointer, you have to write that function in assembly.