OSDev.org

Pardon my potential ignorance, but would the order of learning the "big two" OS languages, ASM and C - matter when wanting to learn OS development.

I know a bit of C basics and I try to grasp the concepts of ASM. Okay, so I may know about some surface-level details like memory is fundamentally a contiguous chunk of 8-bit bytes, a stack being a list of data and instructions in memory that is basically push/pop'd in linear order, etc. But somehow I have a hard time fitting it together.

I ask about good resources to learn them from too as I can get overwhelmed with the options sometimes. Also I tend to read or try practicing one thing and get distracted by another thing, so I have some ADD-like tendency there.

(I assume we are talking about x86 architecture here.)

This automatically involves the question which Assembler to use. (Nasm, Fasm, Gas, ...) That is already discussed here:
viewtopic.php?f=1&t=37025

Normally I would recommend the Assembler tutorial at tutorialspoint, but it contains some errors.

Also the question arises, which mode you want to program for.
a) If you want to write a bootloader for Legacy BIOS PC, then you want to code in real mode.

b) If you want to write applications for Linux or Windows, learn 32bit (=protected mode) or 64 bit (=long mode).
Same if you want to write an OS loader for UEFI.
And same, too, if you want to write a kernel for Legacy BIOS or UEFI.

If you have decided that, then you might want to buy an Assembler book.

Greetings
Peter

I personally learned C from the book C by Sam's Teach Yourself. It contains info about C itself from basic variables to linked lists. ASM is a bit more difficult to learn. I personally learned it from TutorialsPoint, which is a questionable resource in terms of coverage. It explains 32 bit x86 ASM, but not 64 bit. I also learned via experience as well. You can have knowledge, but there is nothing better then practical knowledge from experience.

The book recommendations thread has been largely ignored of late, and much of it is outdated, but one recommendation I made at the very start of it still holds: Assembly Language Step by Step by Jeff Duntemann, which was updated about ten years ago. While old, it still covers the basics quite well. The book is excellent, and doesn't assume a lot of knowledge about other programming languages.

While I would normally recommend learning an easier assembly language first (such as MIPS, which is remarkably straightforward, or ARM, which is a little less so but far more practical than MIPS these days), this book is good enough that it makes even the complications of the x86 design fairly understandable.

There are several other books listed in the pinned thread which are still good, as well. You might want to mine the thread for suggestions, and see which ones you can either afford to buy, or find at local public or university libraries.

Something that may help is to examine the assembly listings generated by C code that you already understand. Take anything written in C (it doesn't need to be OS code), build it with debugging (e.g. "gcc -g") and dump it with "objdump -S". (be sure to turn off optimization ("gcc -O0") so you're not as confused)

The point isn't to learn the details of ASM vs. C so much as to just see that a relationship exists and how one corresponds to the other. Some people learn differently and it may be easier to see it in action. For example, you can read all you want about establishing a "stack frame" but when you see your C function start with: suddenly it all seems "real" and may make more sense.

Seahorse wrote:Pardon my potential ignorance, but would the order of learning the "big two" OS languages, ASM and C - matter when wanting to learn OS development.

No. You need to know both, but it doesn't matter in what order you learn them.

Personally, I learned assembly by reverse-engineering old video games. (And I started with 6502, which is a bit easier to follow than x86.)

If you're planning on writing an OS in C, you must be very familiar with undefined behavior in C.

sj95126 wrote:Something that may help is to examine the assembly listings generated by C code that you already understand. Take anything written in C (it doesn't need to be OS code), build it with debugging (e.g. "gcc -g") and dump it with "objdump -S". (be sure to turn off optimization ("gcc -O0") so you're not as confused)

You might like Compiler Explorer. Add "-m32 -march=i386" to the compiler options to see 32-bit code without any extended instruction sets - perfect for when you're just starting. (And if you're curious about those extended instruction sets, replace "i386" with one of the names in the GCC documentation.)

PeterX wrote:(I assume we are talking about x86 architecture here.)

This automatically involves the question which Assembler to use. (Nasm, Fasm, Gas, ...) That is already discussed here:
viewtopic.php?f=1&t=37025

Normally I would recommend the Assembler tutorial at tutorialspoint, but it contains some errors.

Also the question arises, which mode you want to program for.
a) If you want to write a bootloader for Legacy BIOS PC, then you want to code in real mode.

b) If you want to write applications for Linux or Windows, learn 32bit (=protected mode) or 64 bit (=long mode).
Same if you want to write an OS loader for UEFI.
And same, too, if you want to write a kernel for Legacy BIOS or UEFI.

If you have decided that, then you might want to buy an Assembler book.

Greetings
Peter

I am considering UEFI mode. Even though my UEFI PC has legacy BIOS compatibility mode, it seems like a waste of time to learn real mode.

You kinda need both for OS dev, so, as long as you sufficiently master both, the order shouldn't matter.
I learned assembly much earlier than C because the latter wasn't practically available (I lacked good books and a decent computer).

I went kinda like this:
ZX Spectrum Basic -> Z80 assembly -> Borland/Turbo Pascal -> i8051 assembly -> x86 assembly -> Borland/Turbo C

I learned assembly to make performance improvements in my Basic and Pascal programs and in order to access some interesting resources (devices, memory locations, etc). With OS dev it's somewhat similar as you don't have to use a lot of assembly code, but you can't avoid it altogether because you need it to do some things that your C compiler will not be able to do.

You too can start by implementing small pieces of your C programs in assembly. Maybe not necessarily to gain any performance in your programs, but to get a feeling of what it is like and some knowledge.

What's good about assembly language (or machine code) is that unlike C, it's very non-abstract. When you look at assembly language or machine code for a particular CPU, there you have fixed operand sizes, you have very clear and simple behavior of almost every single instruction, there's no (almost no) undefined or unspecified behavior (of which you have a ton in C/C++) and your assembly language program works exactly the way you wrote it. In C, OTOH, if you violate the abstract rules of the language (which is very easy to do if you don't know them well), you may end up with code that kinda looks OK to you but doesn't at all work the way it looks.

I struggled with C at first because I didn't know its abstract rules. I probably did struggle with assembly as well, but simply because it needed lots of tedious work to make every detail, however simple it was, right. ISTM, with assembly it's a skill that one can normally develop, like skating or playing a musical instrument. With C (and especially C++) one needs a lot of knowledge of those abstract rules of the language. It's learnable too, at least C. Need to have practice in both, though.