Developing os in Assembly

[dilipcs1992]

Hi everyone
i want to develope my own operating system. i have developed a basic operating system in c language using grub bootloader.
but i want to develope my whole operating system in low level assembly language using grub bootloader.
so is there any tutorial out there. or any source code. i need basic operating system printing "hello world" there after i can make on my own.thanks in advance

[Love4Boobies]

If you already wrote a basic OS in C then you should be able to do it without any help. If you can't, you don't know assembly language yet---and that's obviously a requirement for wirting an OS in it. Not that writing an OS in assembly is recommended (due to portability and productivity reasons).

[Tosi]

Look at the assembly listing generated by your C compiler.
Or write it on your own, you should know assembly before setting out to make an OS.

[rdos]

Look at the assembly listing generated by your C compiler.

Not a good idea. C compilers usually generate lousy assembler code.

[Rusky]

20 years ago, maybe.

[guyfawkes]

Assembly coding is all about keeping full control, grub is used mostly by C coders who do not want to get there hands dirty.

Your much better using bootprog and write the simple code you need to set up A20 and go to pmode etc.

[OSwhatever]

Hi everyone
i want to develope my own operating system. i have developed a basic operating system in c language using grub bootloader.
but i want to develope my whole operating system in low level assembly language using grub bootloader.
so is there any tutorial out there. or any source code. i need basic operating system printing "hello world" there after i can make on my own.thanks in advance

Sorry, but I find your post a little bit contradictional. You have already written your own kernel in C using grub as boot loader. Now you want to make your own OS written in assembly.

I'm not going to question your reasons for doing this but if you have already created your own OS in C, you shouldn't really have any problems to get to the hello world part. Take your C code and make the same operations in the assembly language.

[Love4Boobies]

20 years ago, maybe.

Nah, even today. We just tell people they're good at it to trick them into avoiding a premature optimization. For the moment, they're very far from beating an experienced assembly programmer.

[rdos]

Assembly coding is all about keeping full control, grub is used mostly by C coders who do not want to get there hands dirty.

But grub is also useful when you want to multiboot your OS with other OSes. You can just "tear-down" the C-related stuff that grub expects to see in the exe-file. With assembly, it is easy to setup a new environment.

Then, of course, every serious project needs it's own boot-loader when running standalone.

[Combuster]

You can just "tear-down" the C-related stuff that grub expects to see in the exe-file.

Ohai, the liar is back. Grub does not require anything C in a kernel. It also lacks any and all support for PE specifics.

[egos]

My kernel is written in assembler. It has raw binary format. It can be booted directly by grub and by stage 1 boot loader.

[rdos]

You can just "tear-down" the C-related stuff that grub expects to see in the exe-file.

Ohai, the liar is back. Grub does not require anything C in a kernel. It also lacks any and all support for PE specifics.

Yes, but it has support for ELF specifics, and that is related to C. Or at least these formats are not necesary when working in assembler-only.

[rdos]

My kernel is written in assembler. It has raw binary format. It can be booted directly by grub and by stage 1 boot loader.

Grub expects the binary to be in flat memory model, and also assume which selectors are mapped to the flat code/data segments. My main kernel is in a 16-bit segment, and thus cannot be loaded directly by grub. But a dummy 32-bit module can call the kernel and setup the correct register contents that the kernel expects to see. In fact, the kernel & device-driver & file-system image is loaded as a module instead, so the main "kernel" that grub sees is only a stub-loader.

RDOS is loaded like this:

Code: Select all

rootnoverify (hd0,0)
kernel /rdos/kernel/boot/grubload.bin
modulenounzip /rdos/board/amdp6/rdos.bin

When I load without GRUB, I have a menu-interface (second stage) that scans the root directory of the boot-partition for files that end with .bin, and display them in a list. Typically, I have rdos.bin (standard booting) and safe.bin (safe fall-back booting) in the root directory. In that case, it is the second stage that does what grubload.bin typically do with grub + load the actual image into memory + setup protected mode.

[Solar]

Or at least these formats are not necesary when working in assembler-only.

No, of course they are not. ELF was invented so that different toolchains could talk with each other, and that not everybody who wants to write an executable loader / linker / debugger / ... would have to re-start from square #1. No more, no less.

[rdos]

Or at least these formats are not necesary when working in assembler-only.

No, of course they are not. ELF was invented so that different toolchains could talk with each other, and that not everybody who wants to write an executable loader / linker / debugger / ... would have to re-start from square #1. No more, no less.

AFAIK, ELF and PE was invented for applications, not for kernels. For applications, it makes sense to keep symbol-tables in the executable image, and to provide relocation information. It is questionable to have this in OS kernels. There is generally no reason to do run-time relocations in an OS kernel, and there is usually no "application" loader involved in loading and managing pagefaults in the OS-kernel.

IOW, the typical application formats (ELF and PE) does not seem quite adequate for an OS kernel.