Writing an operating system in assembly language

[Casm]

I know that there is at least one member on here who is doing precisely that. But the thing which has put me in mind to do it is that it would avoid the need to coax recalcitrant compilers, such as Visual C, into doing something they weren't really designed for. There would also be an advantage in the disassembly from a debugger having a one to one correspondence with what I had written.

By the time high level functions had been written, which I would be using over and over again, it would probably be a good approximation to writing in a middle level language anyway.

So I just thought that I might collect some thoughts from other members.

[paul84]

what i'm thinking about this matter is

- we definitely have to write the MBR in assembly
- we usually have 2 options for kernel, ASM or C; (i'm writing my OS kernel in ASM)
- we should only write apps for our OS in C (for existing C compiler to compile a source code, the OS has to follow some standard executable formats, or have to create a new C compiler, i'm building 64bit OS, but using the old .EXE (MZ) standard for my applications coz it starts at address 0 instead of 100h like the case of .COM, but i haven't finished my kernel yet so this consideration might change, haha)

[JackScott]

Creating a Cygwin cross-compiler will take you about fifteen minutes of attention and a couple of hours compile time. Coaxing Visual Studio into using that compiler might take another hour. On the other hand, writing your whole operating system in assembly will probably double (if not more) your development time. So assuming that your operating system would take more than about two hours to write in C (which I can guarantee you, it will), writing it in assembly is not the wise option time-wise. Just keep that in mind.

Another point for your consideration is that the number of developers who have a good enough understanding of assembly language to write an operating system is pretty limited (I personally couldn't write a trivial memcpy() in assembly to save my life, and I'm not alone). Later on in development, finding additional developers is going to be difficult.

Additionally, it will mean additional effort in understanding and transcribing any tutorial you find (which will for the most part be in C, with maybe a dash of C++ and the merest smattering of assembly code).

[Casm]

Creating a Cygwin cross-compiler will take you about fifteen minutes of attention and a couple of hours compile time. Coaxing Visual Studio into using that compiler might take another hour. On the other hand, writing your whole operating system in assembly will probably double (if not more) your development time. So assuming that your operating system would take more than about two hours to write in C (which I can guarantee you, it will), writing it in assembly is not the wise option time-wise. Just keep that in mind.

The problem there is that I am allergic to Unix, and even more allergic to Cygwin.

The assembly laguage equivalent of memcpy is:

Code: Select all

lea esi, source
lea edi, dest
mov ecx, 1024
rep movsb

strcpy is a bit more complicated, but still not difficult.

[gerryg400]

Code: Select all

lea esi, source
lea edi, dest
mov ecx, 1024
rep movsb

I'm sure even Visual C produces better code for memcpy than that.

And that's precisely the reason I use C. I may be able to produce better/faster/smaller code than GCC occasionally but over a 10,000 SLOC project GCC gvies me better productivity, fewer bugs and leaves more time for system design, algorithm design, testing, profiling and optimisation.

[Casm]

Code: Select all

lea esi, source
lea edi, dest
mov ecx, 1024
rep movsb

I'm sure even Visual C produces better code for memcpy than that.

And that's precisely the reason I use C. I may be able to produce better/faster/smaller code than GCC occasionally but over a 10,000 SLOC project GCC gvies me better productivity, fewer bugs and leaves more time for system design, algorithm design, testing, profiling and optimisation.

If you think you can improve on that as code for memcpy, I would like to know how. For a start, C would ewither need to push variables onto the stack, or load them into registers, before calling memcpy, and then it would need to load those variables into appropriate registers, before executing the above - which is what it would do, if it had any sense.

Oh, and it would need to clean up the stack afterwards.

[Owen]

A trivial implementation of memcpy for AMD64 (SysV ABI) is

Code: Select all

.global memcpy
memcpy:
    rep movsb
    ret

That said, anyone who has a clue knows that glibc's memcpy implementation is significantly faster, and that the above implementation is very slow and very bad for caches. AMD quote a best case execution time of 11+rCX cycles on K8 assuming DF=0.

[neon]

Most compilers would inline memcpy if optimization is enabled.

Knowing how long it takes to write an OS in C; cannot imagine how much longer it would take in assembly language.

[Casm]

A trivial implementation of memcpy for AMD64 (SysV ABI) is

Code: Select all

.global memcpy
memcpy:
    rep movsb
    ret

That said, anyone who has a clue knows that glibc's memcpy implementation is significantly faster, and that the above implementation is very slow and very bad for caches.

How is:

Code: Select all

mov ecx, 1024
lea esi, src
lea edi, dest

label:
lodsb
stosb
loop label

or even worse:

Code: Select all

mov ecx, 1024
lea esi, src
lea edi, dest

label:
mov al, [si]
inc si
mov [di], al
inc di
loop label

faster than using rep movsb?

[Owen]

Do you actually have a clue how glibc implements memcpy?

[Casm]

Do you actually have a clue how glibc implements memcpy?

There are a strictly limited number of possibilities.

[Owen]

* Points in the right direction: memcpy

This is assuming GCC actually generates a call to memcpy. Its quite often smart and knows that it can do better by itself.

[Casm]

* Points in the right direction: memcpy

This is assuming GCC actually generates a call to memcpy. Its quite often smart and knows that it can do better by itself.

Whatever. It has still got to use the available machine code instructions.

[Owen]

But it demonstrates a point of mine: You argued you could beat GCC for memcpy performance; yet GCC can inline highly optimized versions of memcpy into your code. If you were to do that, on the other hand, your code would be a mess with thousands of versions of memcpy with varying levels of optimization. On the other hand, if you just do "call memcpy" for all needs, you are doing no better than GCC does with no optimization.

But actually you demonstrate another point: If you're "allergic to Unix", how do you intend to avoid falling into the same traps as Unix does? How can you profess to design a better OS if you have no experience with a broad selection of existing ones?

[Casm]

But it demonstrates a point of mine: You argued you could beat GCC for memcpy performance; yet GCC can inline highly optimized versions of memcpy into your code. If you were to do that, on the other hand, your code would be a mess with thousands of versions of memcpy with varying levels of optimization. On the other hand, if you just do "call memcpy" for all needs, you are doing no better than GCC does with no optimization.

If you are writing in assembly language, and you had an instruction like movsb ready to hand, you probably wouldn't dream of doing anything other than coding in line. You would only make it into a function if you wanted it to be C callable.

As for Unix, I have all the experience of it that I could possibly want in a life time.