Page 1 of 2
Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 4:56 pm
by 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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 5:09 pm
by 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)
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 5:46 pm
by 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).
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 5:56 pm
by Casm
JackScott wrote: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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:22 pm
by 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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:28 pm
by Casm
gerryg400 wrote: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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:33 pm
by 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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:38 pm
by 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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:39 pm
by Casm
Owen wrote: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?
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:46 pm
by Owen
Do you actually have a clue how glibc implements memcpy?
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:50 pm
by Casm
Owen wrote:Do you actually have a clue how glibc implements memcpy?
There are a strictly limited number of possibilities.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:56 pm
by 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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 6:59 pm
by Casm
Owen wrote:* 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.
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 7:05 pm
by 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?
Re: Writing an operating system in assembly language
Posted: Mon Jun 13, 2011 7:11 pm
by Casm
Owen wrote: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.