Noob to operating system development, but not a noob 100%.

[andyharglesis]

Based on this source code below that I am writing without reference, excluding the fact that this is strictly long-term memory-oriented and not knowledge fully implemented on each instruction, do you think I have hope to develop an x86 Real Mode bootloader?

I know C/C++, computer science, and operating systems.

Code: Select all

first:
push ebp;
mov esp, ebp;
mov al, 0x0F;
mov bl, 0x0F;
cmp al, bl;
jne next;

next:

I have never written an Assembly program before, but have studied the instructions for about a week.

Do you think I should keep learning as I go, and attempt a small bootloader type of program that calls a BIOS interrupt or the like?

All in all, do you think I'm "ready" for this yet?

[Nessphoro]

Lol, I started OSDev without even knowing C++ or for that matter ASM.
Although I had a very extensive knowledge in C#.

Everything is possible, my friend - that is, if you want it to be and dedicate yourself.

[sortie]

How about you talk a bit about experience, for instance, writing C programs in user-space and what other experiences you have with larger programming projects. We can't judge you from a piece of assembly because it _doesn't mean anything_ unless you give a context, a goal to accomplish. Besides, we can't judge whether you can make a bootloader or operating system. Since you say you "know C/C++, computer science, and operating systems." then you have the basic tools to do it - question is how skilled you are with those tools. However, operating systems development is the brain surgery of programming - it is hard, frustating, and very fun. If you wish to play with operating systems, I would recommend skipping straight to the kernel (and using GRUB) rather than dealing with the bootloader insanity (at least for version 0.1).

Uh, and trailing needed semicolons are bad style in assembly.

Don't think about whether you are ready - just do it and fail! And then you try again. And at some point you'll succeed.

[andyharglesis]

I don't know why you think writing a bootloader is hard; compared to the actual kernel, I'd say the bootloader is pretty straightforward. As for goals, a context? I have many goals I have yet to accomplish in programming, and some will likely never fully happen(like the goal of a GUI-based OS made entirely by myself).
Extra: Why are semicolons bad "style" in Assembly?

[Brendan]

Hi,

Some generic advice:

• for all languages, formatting/style is important. For assembly this means labels should be as far left as possible, instructions should be indented once and any comments should line up in a column on the right.
• for assembly, (unlike high level languages where there is meaningful variable names) you use registers for a lot of things and the register name doesn't tell you much about what the value is meant to be (e.g. "EAX" could be a pointer to a file name as an ASCIIZ string or the price of a goat in Alaska). This means that comments are very important in assembly.
• for assembly, you tend to use instructions for their effect rather than their semantic meaning. For example, "lea eax,[ebx+273]" looks like it loads the effective address of something into EAX (e.g. maybe EBX is the address of a structure and you want a pointer to a field in that structure), but it could just as easily be code to convert degrees Celsius into degrees Kelvin that has nothing to do with loading an effective address at all. This means that comments are very important in assembly.
• for all languages there are only 2 kinds of bugs. The first kind of bug is code that doesn't do what the programmer intended it to do. The second kind of bug is code that does do what the programmer intended it to do (but the programmer's intentions were wrong). For assembly, "debugging" often means checking that the comments (which describe the programmer's intent) do describe a sane/correct algorithm without looking at the instructions at all; and then checking that the instructions actually do what the programmer intended. Basically; this means that comments are very important in assembly.

Of course (just like other languages) some things are so obvious that comments aren't need. One example of this would be setting up a "C style" stack frame, which is something that all assembly programmers should recognise easily without any comments. Ironically, for "pure assembly" code (e.g. a boot loader) setting up a stack frame is also an unnecessary waste of time.

Now, here's some example code:

Code: Select all

first:                
     push ebp
     mov esp, ebp

     mov al, 0x0F         ;al = the size of your dog's testicles
     mov bl, 0x0F         ;bl = the size of your cat's testicles
     cmp al, bl           ;Are your dog's testicles the same size as the cat's testicles?
     jne next             ; no, get the dog and the cat neutered
                          ; yes, get the dog and the cat neutered 
next:

All in all, do you think I'm "ready" for this yet?

No you're not ready; but neither am I, and neither is Linus Torvalds, Andrew Tanenbaum, Steve Jobs or Brian Kernighan. Nobody ever is, partly because the goalposts keep shifting (e.g. if you waited until you were ready, then "ready" would change and you wouldn't be ready).


Cheers,

Brendan

[andyharglesis]

Depends on your definition of a "bootloader" per se. If you mean the most basic software to load the kernel and other images in memory, yes, the stack frame/call stack would serve no purpose to the instructions since they're all straightforward mostly. But some hobbyists like to call a "bootloader" any software executing on a bare system(e.g. as in freely under no operating system). In such a case, you could execute whatever you wanted, and could technically implement a stack frame for whatever program purposes.

[bluemoon]

Stack frame is only useful for stack trace debugging, and it almost useless for assembly program or boot loader which parameters and "local variables" are usually on registers.

But some hobbyists like to call a "bootloader" any software executing on a bare system

I disagree. A boot loader is a boot loader, bare system is a bare system.

[Yoda]

do you think I have hope to develop an x86 Real Mode bootloader?

Yes, you have. But is it really needed? There is a lot of powerful bootloaders around. Get any convenient and proceed directly to OS.

[andyharglesis]

It's a great way to work with the architecture and learn a thing or two to load your OS with your own
self written software, so I'd have to say that it's worth the extra time to "re-invent" some of the wheel.

Plus, my own bootloader can't go wrong if I'm writing it to load my kernel(well, it CAN, but it's geared only to my kernel).

Alas, I know plenty of Assembly instructions, and BIOS interrupts, so the difficulty should dramatically decrease.

[BMW]

Based on this source code below that I am writing without reference, excluding the fact that this is strictly long-term memory-oriented and not knowledge fully implemented on each instruction, do you think I have hope to develop an x86 Real Mode bootloader?

I know C/C++, computer science, and operating systems.

Code: Select all

first:
push ebp;
mov esp, ebp;
mov al, 0x0F;
mov bl, 0x0F;
cmp al, bl;
jne next;

next:

I have never written an Assembly program before, but have studied the instructions for about a week.

Do you think I should keep learning as I go, and attempt a small bootloader type of program that calls a BIOS interrupt or the like?

All in all, do you think I'm "ready" for this yet?

Lol what is that code for? Making sure 0x0F isn't equal to 0x0F?????? Even if it is its still gonna go to next.