OSDev.org

Hi all,

I was just wondering what your thoughts/insight is on how much assembly one should learn before making an OS. Someone told me that really there isn't much assembly involved, a minimal amount, to quote: "it's not needed knowing how to write assembly is but a very small subsection of a subsection of what osdev entails"

Do you guys agree, or disagree? I'll want to write an OS in zig, but I'm very inexperienced when it comes to assembly.

Thanks for your posts!

I got away with not knowing much assembly language at all. I certainly hadn't written any programs in assembly. However, I did have a pretty decent knowledge of how a computer worked at the register level. I learned what assembly I needed as I went, and made sure my knowledge of how a computer works kept ahead of what I was trying to implement.

You don't need to use a lot of assembly language to develop an OS but, as we see demonstrated many times on these forums, a lack of knowledge of the targeted processor, and how it works, leads to baffling mistakes. For example, on the x86 processors you need to understand - apart from the simple instructions - descriptor tables, interrupt and exception processing, paging, etc.

A very good way to extend, and test, your understanding of the processor is to practice writing assembly language programs for it and use a debugger to watch how they work. A very good prerequisite for writing assembly language programs is a good understanding of the assembly language of your chosen processor.

I would recommend that anyone aims to achieve a good level of understanding of the assembly language of a processor before attempting OS development for it. You will save a lot of not only your own time but also that of other people.

Secondly I would recommend avoiding (what I consider to be) the mistake of writing an OS entirely in assembly language rather than using the benefits confered by a higher-level language.

I will add that there are certain things you can only write in assembler, and certain things you might be able to get away with in C, but assembler may be the better choice. memcpy() comes to mind: There is a very simple way to write it in C, but there are compiler versions that turn that into an infinitely-recursive function.

Or else, bootstrapping the relocations of a dynamic ELF program. Normally, the loader should do it, but there are situations where the program must do it for itself, and before that is done, referring to external functions or constants may not work correctly. It may be possible to make a C compiler emit code that works, but personally, I'd have too much anxiety about any later change making the compiler hoist some initialization or constant access.

But yes, for the most part, these days you should stick to a higher-level language and use inline assembler where necessary for the few instructions that need it. In case of OS development, the only things that really need to be out-of-line assembler are the start function (as it is often needed to establish a stack and initialize the frame pointer chain), the first-level interrupt handlers (since they similarly have no standard calling conventions), and the stack switching function for the scheduler (since typically, C compilers don't allow you to muck about with the stack pointer in inline assembler).

I started out writing everything in assembler. Today, for complex devices, I will use C for the compexity and assembler for the interface with other drivers and user space. My compiler (Open Watcom) will not output very efficient code for the segmented memory model I use in kernel, so time critical code is usually written in assembly.

For user space, which use a flat memory model, I almost excusively use C++.