OSDev.org

Hey, guys,

I've just started a blog about operating systems and I'm working on a series of posts on learning assembly language. The goal is to introduce readers to enough assembly so that they can ultimately build their own OS.

For the first post in the series, I walked through creating a "Hello, World!" program, but I'm not sure what other aspects of assembly I should cover. I'm thinking that I definitely need to go over conditional statements and looping, the different modes of execution and how to switch between them, calling assembly language from C, and interfacing with hardware (drawing to the screen, etc). I don't know a whole lot of assembly, so I'll be learning some of this as I go.

Are there any topics that are necessary for building an OS that I haven't considered? What pieces of knowledge about assembly programming are crucial when it comes to building an OS?

Hey, just wanted to tell you that I'm looking forward to your tutorials. Keep up the good work. Cheers.

rps wrote:For the first post in the series, I walked through creating a "Hello, World!" program, but I'm not sure what other aspects of assembly I should cover.

Assembly needs a good comprehension of the underlying architecture. So, I'd basically start with the intro of the architecture. Before you begin with the source code, you should be able to explain how you'd interact with the hardware. Moreover, I couldn't find a grasping explanation about the registers of the x86 architecture in that series. At the very least, you should be able to the demonstrate the existence of 16-bit registers, 32-bit registers and the 64-bit registers. Moreover, you should elaborate why you preferred to chose the 64-bit mode in the first place.

Just some suggestions. I hope you'll come out with an excellent series.

I haven't really read your x86(-64) assembly tutorial, only took a very quick glance of it. Here are some comments and suggestions:

• If you're going to describe pipeline operation (although you haven't used that terminology) then go one step further and explain how programmers can use that knowledge to their advantage; I'm thinking of stuff like avoiding pipeline stalls and false dependencies (e.g., why ADD/SUB are almost always faster than INC/DEC), talking about the OoO execution unit and SMT (HT in x86 terminology). Explaining things like branch prediction, register renaming, speculative execution, RISC vs. CISC and the role of microcode, and caches (including prefetch queues and whatnot) would also useful.
• You have only talked about assembly language in usermode---that's only useful for applications. Describe kernel mode: system data structures such as descriptors, the types of interrupts and the role of interrupt handlers, paging and (optionally) segmentation, the role of FS and GS and long mode, how to switch between operating modes, how context switching is works, etc.
• Since any sane person uses a HLL compiler for most of their OS development, you'll want to touch on the various compiler ABIs (type representations, calling conventions, stacks and stack frames, heaps, etc.) and maybe even inline assembly if you feel like it.

From what I've seen, assembly in itself is not usually the problem - it's always the computing architecture in its wider scope. People tend to see higher level languages (and even assembly in the worst cases) as a black box. It often serves for doing simple work, but too many people lack some things that are not strictly part of assembly, such as how each possible construct in C gets converted to its assembly counterpart. Many of the newcomers here seem to have absolutely no idea of how to read objdump output as a consequence even though they are able to look up individual opcodes.

I haven't read the tutorial itself and have no idea what your intended scope is, so consider and ignore as necessary.

Sandras wrote:Hey, just wanted to tell you that I'm looking forward to your tutorials. Keep up the good work. Cheers.

Thanks, hopefully they will prove useful.

berkus wrote: 1. knowledge of assembly language (this you seem to cover)
2. knowledge of a particular assembler tool (e.g. gas vs nasm)
3. knowledge of certain quirks (e.g. masm addressing modes assumptions)
4. as a bonus, knowledge of assembly for different types of CPUs (e.g. ARM vs x86, x86 vs x86-64)

Knowledge of assembly language and also of an assembler (nasm) will definitely be covered. I'll cover any quirks that are people are likely to run into as best I can. Right now, I'm just covering x86_64, maybe in the future I will write about ARM.

Chandra wrote: Assembly needs a good comprehension of the underlying architecture. So, I'd basically start with the intro of the architecture. Before you begin with the source code, you should be able to explain how you'd interact with the hardware. Moreover, I couldn't find a grasping explanation about the registers of the x86 architecture in that series. At the very least, you should be able to the demonstrate the existence of 16-bit registers, 32-bit registers and the 64-bit registers. Moreover, you should elaborate why you preferred to chose the 64-bit mode in the first place.

Just some suggestions. I hope you'll come out with an excellent series.

Good suggestions. I'll cover more CPU architecture in the next part of the series and I'll add a "Why x86_64?" to the first part of the tutorial. At some point, I will cover registers more in depth and talk about different sizes, but I don't think it's necessary knowledge for the "Hello, World" example.

Love4Boobies wrote: If you're going to describe pipeline operation (although you haven't used that terminology) then go one step further and explain how programmers can use that knowledge to their advantage; I'm thinking of stuff like avoiding pipeline stalls and false dependencies (e.g., why ADD/SUB are almost always faster than INC/DEC), talking about the OoO execution unit and SMT (HT in x86 terminology). Explaining things like branch prediction, register renaming, speculative execution, RISC vs. CISC and the role of microcode, and caches (including prefetch queues and whatnot) would also useful.

These topics are more advanced, not stuff that one should worry about when writing "Hello, World". If I cover those topics, it will be in a later part of the tutorial.

Love4Boobies wrote: You have only talked about assembly language in usermode---that's only useful for applications. Describe kernel mode: system data structures such as descriptors, the types of interrupts and the role of interrupt handlers, paging and (optionally) segmentation, the role of FS and GS and long mode, how to switch between operating modes, how context switching is works, etc.

Yup, I definitely plan on covering kernel mode.

Love4Boobies wrote: Since any sane person uses a HLL compiler for most of their OS development, you'll want to touch on the various compiler ABIs (type representations, calling conventions, stacks and stack frames, heaps, etc.) and maybe even inline assembly if you feel like it.

Once I've covered a fair amount of the assembly knowledge necessary for building an OS, I plan on dedicating part of the tutorial to how C code is translated into assembly.

rps wrote:I've just started a blog about operating systems and I'm working on a series of posts on learning assembly language. The goal is to introduce readers to enough assembly so that they can ultimately build their own OS.

Are you aware of existing ASM tutorials and books? What are you intending to do different, that warrants you writing a tutorial of your own?

(Personally, I felt that "The Art of Assembly" covered everything I needed to know...)

Solar wrote:

rps wrote:I've just started a blog about operating systems and I'm working on a series of posts on learning assembly language. The goal is to introduce readers to enough assembly so that they can ultimately build their own OS.

Are you aware of existing ASM tutorials and books? What are you intending to do different, that warrants you writing a tutorial of your own?

(Personally, I felt that "The Art of Assembly" covered everything I needed to know...)

Great question.

I currently intend to cover all the assembly language knowledge that one will need to develop an operating system, so my tutorial is more focused than most. Further, my tutorial will target x86_64 assembly. Most of the tutorials that I'm familiar with were written before 64bit processors became common place.

In addition, my tutorial will be prettier. The formatting of most assembly introductions is atrocious. It's 2011, we have syntax highlighting.

Of course, my intention is to create a tutorial of a higher caliber than any of those currently in existence. Ultimately, I hope that my tutorial will prove to be the most engaging of any produced. Above all, I want people to want to continue reading through each part. I don't want it to be a grind.

rps wrote:It's 2011, we have syntax highlighting.

Which is of very limited value for ASM source, and hardly a showstopper for any of the ASM tutorials around.

rps wrote:Of course, my intention is to create a tutorial of a higher caliber than any of those currently in existence. Ultimately, I hope that my tutorial will prove to be the most engaging of any produced.

Well enough. However, consider this:

rps wrote:I currently intend to cover all the assembly language knowledge that one will need to develop an operating system, so my tutorial is more focused than most.

Unless I am severely mistaken, you cannot have both. Either your tutorial will cover only a specific portion of the language ("the part needed to develop an operating system", whatever you think that would be), or it will be complete, i.e. engaging to the general public.

To answer the actual question, the amount of ASM you need to develop an OS could probably be covered on four or five pages. GRUB takes you to protected mode. You need some lines of ASM for loading GDT, invalidating TLB and wrapping your interrupt handlers, the rest can be done in C/C++ or whatever high-level language you chose. (Note that I don't judge whether it should be done this way, just that you could get away with a two-digit number of ASM lines and still be fully functional. (Guesstimate, haven't done this myself.)

Solar wrote:Note that I don't judge whether it should be done this way, just that you could get away with a two-digit number of ASM lines and still be fully functional. (Guesstimate, haven't done this myself.)

Just for some real-world data, my kernel has 3084 lines of C and 435 lines of assembly, 92 of which are used for initialization, 104 for interrupt handling, 39 for port I/O stubs, and 200 for stubs for getting/setting all the control registers/flags/etc. The system as a whole has 885 lines of assembly and 18888 lines of C, so the kernel is comparatively asm-heavy.

NickJohnson wrote:Just for some real-world data, my kernel has 3084 lines of C and 435 lines of assembly, 92 of which are used for initialization, 104 for interrupt handling, 39 for port I/O stubs, and 200 for stubs for getting/setting all the control registers/flags/etc.

And if you continue to work on the kernel (like, adding USB support, or SCSI support, or <whatever> support), would you expect the ASM code to grow in relation to the C lines added? Or does your kernel already have about all the ASM it will ever get? (Which is what I would expect, seeing how you have the ISR and register stubs in place.)

It's a microkernel, so it probably won't grow significantly at all, except maybe when I eventually add SMP support. The only things I changed in the last year or so were completely in C, and mostly involved adding new system calls for process/thread management. The stubs I have pretty much encompass all of the useful privileged instructions, so it has effectively the maximum amount of assembly for a kernel with a minimum amount of logic written in assembly.

Edit: also, these stubs all look roughly like this: which means a lot of the lines are just assembler labels or directives. If I were to combine all of the stubs into one file, or use inline assembly, this would cut down on the assembly line count significantly. I used sloccount to get those figures, and sloccount interprets this as 7 lines of assembly, when really there are only 3 instructions. In addition, I'm not sure all of the stubs are actually used, but at least most of them are.

Note that you'd need assembly for a fairly simpler debugging purpose. I always considered assembly as an counterpart of C, considering how they are linked with the hardware level programming. But, Solar has a point. You already have enough, and just enough, assembly tutorials lying around. Some of them are more than just good, already.

It doesn't hurt to give the new one a shot, though.

Hi,

in my opinion if your blog is os development tutorials you shouldn't write about teaching assembly, there are resources out
there for this purpose, just go directly to your topic and at first mention the required knowledge, the required level of knowledge of assembly, C , etc...

Also, I think you should take a look at other tutorials, and try to cover topics where other writers didn't, so don't re-invite
the wheel, write tutorials about more advanced topics, about stuff never been written before, or don't... that's just my opinion.

Anyway Good luck.

I have received some positive responses regarding the first part of the tutorial, so I'm going to stick with it. People seem to like it. It's useful.

Thanks for all of the feedback and ideas.