OSDev.org

MilkyGirl wrote:So every process has its own stack?

How do you figure this exactly?

The "stack" would reside in memory, but when I load code from memory, would that already be on the stack?

If not, where would the stack start and end, and where would the stack reside that's not where my bootloader code would be?

Or is the stack briefly some scheme to give the illusion of data in memory? If so, why use it, since all data can theoretically work without it, unless it's hardware specified, and in that case we go back to the drawing board.

I don't get the real purpose, understanding or effectiveness of it really much at all honestly, even reading 500 pages of the "Art of Assembly" guide.

finer details aside (as theres enough here already), the stack's (aka "call stack") primary purpose is to store an address so the control-flow can continue after a subroutine. - A subroutine can be called from multiple locations, so we need to store which location it was in order to return to the correct point. (call and ret are asm functions that will manipulate the stack for you).

As the stack is used to keep track of where the thread (processing unit) is, you must have one for each thread.(5 people reading a book, they must all know which page and line they are currently reading).

The stack is created at task/thread creation time; When your application is loaded, your application will reserve a space in memory (The data segment) for the stack.

MilkyGirl wrote:I know Assembly, never written a program

Hmmmm you are contradicting yourself there.

MilkyGirl wrote:I know computer architecture, I've been a programmer. What confuses me is the hardware stack, what I said above, and how all of this works in general practice.

Hmmmm you are contradicting yourself a second time.

Milkgirl, here is a simple question: What is the difference between "Pass By Value" and "Pass By Reference"?

If you can't understand how SS:ESP works then you are never going to be able to write an Operating System.

The best piece of advice is simply give up.

OP, I don't think you know the architecture well enough. Take Brendan's advice. Do what he says.

You don't know enough yet to start. However I applaud you for not asking us how one would go about writing an OS in Visual Basic 6...

tom9876543 wrote:The best piece of advice is simply give up.

That's very nearly the worst and most patronising "advice" that I have seen on this forum. (And that's saying something.) The OP may not understand this particular aspect of low-level programming, but demonstrates a willingness to learn.

My advice would be to write a few simple assembler programs including subroutine calls and step through them in a debugger such as gdb, watching what happens to registers and memory to see how they change with each instruction; in particular look at SS and the memory it points to when you call a subroutine and return from it. Then perhaps look at the assembler output produced when compiling a simple C program and try to understand what each line does (that can be quite tough as compilers tend to put in a lot of odd-looking stuff). In particular, try to understand how the compiler uses the stack to store local variables, and ask yourself why this might be better than storing them in memory or in registers. (Hint - think what happens if you have a recursive function.) Concepts such as the stack can be very difficult to grasp at first; then suddenly it just clicks and becomes blindingly obvious.

I think you need to practice a little more simple assembler stuff before jumping too deeply into OS development, and you're going to run into a few more brick walls yet. Keep that open mind and willingness to learn and don't be put off by patronizing know-it-alls. And read the Intel and AMD manuals; you won't understand it all first time through (or second), but they are the ultimate reference material.

Brendan wrote:Once you've got that setup and working, start learning assembly by writing your own code to print one character to the screen (this is only about 3 instructions, but will get you used to using a BIOS function). Once that works, try writing a "print string" routine (learn simple loops), then figure out how to load a second sector from disk. From there you can decide what to learn next yourself.

I second Brendan's advice. Learning assembly might be tricky sometimes, so be sure to have a copy of Intel manuals (especially volume 3) and read in details about the very few instructions you've seen in the Brendan's code - they might give some interesting hints. Your eye might catch on some other instruction descriptions while doing this. Don't hesitate and give them a go in your code, observe how they work in debugger and compare to what is said in the manual; it will make it easier comprehending the manual in the future (you will correlate the official documentation terms with what you have in your head).

And good luck.

MilkyGirl wrote: And face it, good programmer or not, writing an operating system is daunting unless you're a pro with years of experience here, and you actually can understand all of those complicating figures in the microarchitecture, aside from endless and hypocritical terminology across endless aspects of design and actual implementation.

Yes, I agree.

I don't know about the pro aspect. When I started my OS 1988, I had some prior experience with DOS programming (as a novice programmer), and some experience with Z80 assembly. I didn't have the luxury of emulators or C compilers for my intended target (386), so I had to create the debugging tools myself inside of the OS. I also had an MSc in electronics, and part of that a class in computer architecture. I bought the Intel manuals at a fair.

You don't need to know all fancy design elements of traditional OS programming (it might even be a disadvantage to know too much of them as then you will probably write an *nix clone or M$ clone). It is a good thing to know of possible algorithms at a superficial level so you can decide between options you might not come up with yourself, but by knowing too much you become biased to select some.

You also don't need to be able to understand figures of microarchitecture, or details of how to optimize for various processors, but you need to know the assembler language of the target, and some details on how it works internally, like segmentation if you use x86.

The best way to learn what you need is to start with a bootlader (using an debugger) and learn what you need as you write the code. I wouldn't start with a tutorial, as then I'd fail to learn important aspects already solved in the tutorial, and fail to understand why it was like that. A tutorial would also bias me towards *nix or M$, increasing the risk for just writing a clone.

I'd agree with your comments about tutorials. Most of the ones that I see seem to cause more problems than they solve. We see many simple questions here where people have blindly copied a tutorial (perhaps incorrectly) without really putting any thought into what it really means. And they leave people thinking "what now?" after they have duplicated the code in the tutorial. Having said that, I'm not sure that starting from scratch is the best procedure; there are just too many things to reinvent.

I would suggest that, at the very least, you read a few books about OS design so that you understand the problems, the existing solutions and can perhaps come up with your own ideas. The book that first inspired me was Tanenbaum's Operating Systems: Design and Implementation. I believe that's inspired a few people. As I couldn't afford the £100 that it cost to buy Minix, that encouraged me to implement Minix on an IBM PC (one of the original amber-screen, sewing machine "portable") by typing in the code and filling in the missing bits (and there were quite a few of them), which is where the learning happened. Still a tutorial, true, but at a rather higher level than the simple bootloader ones.

Other books that I found useful were Burgess Developing Your Own 32 Bit Operating System and The Design and Implementation of the 4.4BSD Operating System. Great books, and I'm sure that everyone has their own favourites, but to my mind no-one can beat Tanenbaum for clarity and coverage at just the right level.

iansjack wrote: I would suggest that, at the very least, you read a few books about OS design so that you understand the problems, the existing solutions and can perhaps come up with your own ideas. The book that first inspired me was Tanenbaum's Operating Systems: Design and Implementation. I believe that's inspired a few people.

I used "Operating system concepts" by James L Petersson and Abraham Silberschatz. It describes a range of OSes of that time (early 80s), but I cannot say I used much of this material when implementing my own OS. Maybe I borrowed the C-Scan algorithm, for file system buffers, but that's just about it. I also couldn't use much of the multi-programming material since there wasn't any x86 SMP processsors at that time, so that part was quite obsolete. They don't even describe things like spinlocks, but theoretize around this on a too high level that has no practical implementations.