OSDev.org

This is a bit misleading.

I do not think it works like this, this imply that ASM coder, just write the same code over and over again.
This is not the case, most things a OS Dev codes is new to them.
So the ASM code works just like the C coder, get the code working without bugs and than optimise the bottle necks.
Now if your lazy or busy, you may missout the optimising part.
So optimising is part of coding for any language, if you miss it out in ASM, you will in most cases end up with slower code than if you miss it out when coding in C.

With asm you will get more help when starting, yes that true, but once your down the road, you will make faster progress with C.

About 80% of the coder who want to help with DexOS only know C .

I am comfortable with C, it's ASM that I'm starting.

Choose what you are more comfortable with. In my case, I am not a C coder so I am writing my kernel entirely in Assembly. However, I am not proud of having done it. One of the things that you have to consider though is to think about how other programming languages are going to communicate with your kernel, system calls and etc. For example, I have seen many OS Developers writing kernels in Assembly and using the Register calling convention. That makes it VERY unlikely for somebody with knowledge of C to be able to extend that kernel or write drivers for it. I used the STDCALL calling convention throughout my kernel for example because I knew GCC and other C compilers support that calling convention.

To summarize, it doesn't matter which programming language or assembler you choose. Choose what you know how to program in. When writing code, also make sure you think about the future of the code and not the present situation.

You should really look disassembled compiled C to understand that compiler "thinking" is worse than programmer thinking. The compiler will produce faster and smaller code, only if well programmed and anyway it is limited to its own algorithm.
ASM code is better, faster and smaller than C and it is preffered for level 0. Anyway, at level 1 and high (Device drivers, Developer enviroment and user-level applications), code becomes too complicated to optimize and write it at the same time, so most people will prefer C, and for user-level C++. Even so, there is device drivers written in ASM. At low-level ASM is the best language.

As far as I'm aware an O(n^3) algorithm will be just as slow in Assembly as it will if it were written in C, C++, Java or even Brainfuck.

No, no. It will be still be O(n^3), but that just signifies a number of operations, you can make each operation faster in asm or C than other languages.

What I am trying to say is that difference is largely irrelevant.

If you try to write something in brainfuck you'll find that the difference isn't irrelevant. Brainfuck programs are slow.

Only if you use an interpreter

(There are compilers out there)

The compiler would have to be perform much more intelligent optimizations than gcc to produce code of the same speed because of the operations in brainfuck, so I doubt such compiler exists.

If you can code C, use C, it's that simple. If you find something that ends up being a bottle neck, you can always replace it with an assembly version, and at this point, you know it works properly, so if you break something, it's much simpler to track down the problem. Just use standard C calling conventions in your assembly code, then you can mix and match or replace very easily. If you are writing a device driver, you can write the low-level access code in assembly, and then use C for storing structures with information about device queries and giving a global interface to grab info or communicate with the driver/device. I am trying to get most asm out of my kernel so I am can re-compile for other platforms easily, but I am leaning more towards sticking with x86 only, but always want the option. I used to have to use an ASM file for each driver, because I had a specific header I wanted (so i could get info about driver type, function locations, etc), but I have since changed to using coff files with relocations still in them, so I can move my drivers around, and find information by searching symbols. Now all my driver code can be C, or ASM, or both, but there are no requirements on locations as long as you have the Driver Info block and the initialize functions available . My old OS, I wrote the kernel in 100% assembly, however I made it C compatible so my user apps could be written in C (like my GUI was).

It really depends on what you value you more. Speed? Performence? Then go for ASM but if you want you OS to be more reliable? stable? then go for C (or even C++ if you want to go object oriented as my OS is).

If you want an example of a 100% OS the check out MikeOS. This is a purely teaching project designed to show you what it takes to make an OS out of ASM.

If you want a good C OS then there are plenty of them on the project list on the wiki. Check out FritzOS over here for a C++ OS, this is what i am baseing my OS on.

But overall if is a matter of personal preference. If you know C or C++ then code it in C. If you want a more of a challenge or know ASM (well) then go for ASM. Its up to you on that matter.

Harry.

I almost agree with this, up to the point of reliability... there is nothing unreliable about writing assembly code, unless you don't know assembly well, same goes for C though, if you suck at C, chances are writing an OS in C will have tons of bugs/buffer overflows, mistakes, etc. I don't blame assembly for being unreliable, but the person who produces unreliable code can do so in any langauge. C is not more stable than asm, in asm you know 100% what you are writing, C it is up to the compiler to make optimizations, etc. Try compiling C code with multiple compilers and viewing the asm output, chances are they aren't identical. Compile assembly code with any assembler, and it's going to be the same output (ok, so syntax issues between assemblers make this kinda hard somtimes, but you get the point). If you write good code, it will be reliable in any langauge. I consider myself 'better' at C (and C++) than assembly, yet I had no issues with unreliable ASM code in my 100% asm OS, but I did find it harder to implement new features and keep my projects clean (because i'm not as familiar with it), plus portability was a big issue for me, so I switched to C. My kernel is larger and less efficient, and no more reliable for doing so.

I agree with that 100%. When I mentioned reliabilty, I was mainly implying that it is easier to code badly in ASM than in C. This is because you are coding at a lower level, therefore there is more to take into consideration than when coding in a middle level language like C.

Personally I feel that it is down to personal preference. If you know ASM then go for ASM, if you know a language like C or C++ then go for that! It is all up to you.

Harry

I just wanted to clarify that ASM is not unreliable, and if you're good at it. Also, in C, I have to do a bit of a hack job (depending on compiler) to get certain things to work that are pretty trivial with ASM, which sucks when you try to cross compile in GCC, turbo c, tiny c and msvc . I can just write it in NASM, compile to linkable file format, and it just works, i have no reason to ever use another assembler (unless it has a better/different object file format or something), however I have tried tasm, gasm, masm, and nasm, and have liked nasm the best for it's size, simplicity,syntax and output formats, but a lot of that is personal preference. Some people like AT&T assembly, I can't stand it, and I hate how GCC's inline assembly syntax is, I much prefer the old borland turbo C style inline asm, just type it in ASM like normal, and use your variable names like normal.