C or ASM?

[Bobalandi]

Alright, I haven't gotten far into my os development, and I have been writing it in mainly C with little ASM, but I never thought whether I should code it completely in ASM instead. I haven't gotten far, so I decided to ask before I did. What is the main reason people write their operating systems in ASM?

[Ready4Dis]

Alright, I haven't gotten far into my os development, and I have been writing it in mainly C with little ASM, but I never thought whether I should code it completely in ASM instead. I haven't gotten far, so I decided to ask before I did. What is the main reason people write their operating systems in ASM?

Well, I wrote a small OS in 100% assembler, it was 32-bit, supported preemptive multi-tasking, memory manager (with paging, and demand page loading), vesa driver (basic functions only, like setting the screen resolution, getting a pointer to the screen buffer), keyboard and mouse drivers, ide & file system driver (ide + fat12/16/32). The kernel + all drivers was around 8k, i have since canned the ASM only implementation in favor of a C version (with ASM used for critical/platform specific sections), the reason for doing so was 2 fold, first was portability, and the second was C is much easier *for me* to program in (i can write efficient size/speed asm code, but it takes longer to get results). Of course there are downsides as well, but for my OS, I feel C is the best choice right now. Even though my kernel was full ASM (including all said drivers), my GUI was written in C.

[Bobalandi]

Thanks, that's exactly what I needed to know, I think I will stick with C then.

[crazygray1]

I think it really depends on what you want to do.
Are you looking for portability? use C
Or do just want to have complete control over everythin? Use Asm



Do you want a mix? use both(of course you'll have to for some parts)

[JamesM]

Ease of programming is subjective. Just use whatever you feel most comfortable with. Remember that you must know your entire selected toolchain inside out.

[Dex]

I written my OS in 100% ASM, because i like coding in ASM, if i liked C more, that's what i would of used. ASM OS in most case's are not any fast, than if they were coded in C. They would be small in size, but that's it.
So it's down to which language you like best or are best at.

[Ready4Dis]

Ease of programming is subjective. Just use whatever you feel most comfortable with. Remember that you must know your entire selected toolchain inside out.

yeah, that's why I put the *for me* in there . Some people find other languages easier than others. I can program in x86 assembly relatively decent, but I am very good with C and C++. I do still use assembly for certain things, like my rasterizer for my software 3d engine where size and speed are a must, but for something like a game engine i would not write in assembly . Other people find it fun and will write the entire thing in asm, some people prefer *insert lanauge here*, just personal preference, but C is a very good choice for OS implementation, it's popular, tons of compilers, tutorials, it compiles to native binary of target (so no virtual machine/intermediate language to process), etc. So if that's what you prefer, go for it.

[Bobalandi]

I written my OS in 100% ASM, because i like coding in ASM, if i liked C more, that's what i would of used. ASM OS in most case's are not any fast, than if they were coded in C. They would be small in size, but that's it.
So it's down to which language you like best or are best at.

Thanks, yah, for some reason I thought ASM OS's would be much faster, but apparently not. Thank you.

[Ready4Dis]

I written my OS in 100% ASM, because i like coding in ASM, if i liked C more, that's what i would of used. ASM OS in most case's are not any fast, than if they were coded in C. They would be small in size, but that's it.
So it's down to which language you like best or are best at.

Thanks, yah, for some reason I thought ASM OS's would be much faster, but apparently not. Thank you.

Typically, the speed of the OS is more defined by the efficiency of your algorithms. Compilers have gotten much better at optimizing, but I can still get tighter loops in asm than C, and save a few clock cylces here and there, but overall, the majority of time is spend in context switches, scheduling, and running user apps . Optimizing prematurely is the root of all evils. Design it so that it can be replaced as well... I have written many versions of the same modules, and i can swap them in/out easily, so if I find that my memory manager isn't as efficient as I need it (takes to long to allocate or deallocate, whatever), I can re-write it without breaking the rest of the code, since my memory manager only has a few functions that are available, which don't rely on how the manager actually functions. I can use a stack, bitmap, whatever, nobody cares except that module. Same for other things, my scheduler is responsible for picking the next task, my first implementation was round robin, and simply ignored priorities (although i have them there for when i am ready to deal with them). The application doesn't care how it's sceduled, and doesn't even know it was interrupted, so if I get done, and find out that my kernel is spending to much time in the scheduler and not actually running apps as much, i can re-write it in asm to same a few instructions, or write parts of it, or come up with a better algorythm. There is no 'best' way to do many things, it is very specific on what your goals are. Some people want a gaming os that is single tasking, or very limited multi-tasking (video, ai, audio, input, physics), it might be preemptive, or it might not be. You may not need to update audio as often as physics, etc. Or you may want to run your physics, etc at a predetermined rate of speed (so you want it called at a specific time frame, rather than whenever cpu is available). Of course, these are different design's than a desktop OS that is running a GUI with a word processor and web-browsing. First come up with the 'what', then fill them in as SIMPLE as possible (ignore future features like I did with my scheduler if needed), then you can start replacing them with GOOD implementations, and if something breaks you know what module you were working on that broke it, because you know the other code works as advertised with the simple version. My first memory allocator only allocated 4k at a time, once that was working properly, i replaced it with a module that can allocate arbitrary sizes, and didn't break anything else that relied on it, and it got other parts of the OS working that I needed to have working before I worried about my malloc/free imlpementation, without having to code a lot of things over again (a simlpe malloc/free that works only on blocks takes very little time). So, with about 15 minutes in my allocator, 30 minutes into a round robin scheduler, I had memory management, and multi-tasking implemented. You can leave them if they suffice or relpace them when you find them to be not sufficient. The langauge you are using doesn't really have much to do with it, as long as it meets the needs of your goals.

[bewing]

Some history: UNIX was originally written in ASM. Once K&R had this concrete example of how an OS should be coded, they were able to invent the C language, and decompile their ASM code into their new C language. Knowing what the C code was supposed to compile into, helped them build their compiler, too. So, if you are interested in creating a new programming language (like I am) then writing an OS in ASM is one way to start. Similarly, if you are interested in designing a new & better CPU chip (like I am), it is very beneficial to struggle with the limitations of a current CPU's opcode set -- to find out what is missing, and what could have been done better.

Another reason to code in ASM is that the debuggers all debug in ASM. Debugging is more convenient when there is a 1:1 relationship between your code, and what the disassembler is showing you.

A HLL compiler will generally force you to abide by its calling sequence, especially if you are trying to create position-independent code, that will run in physical memory, for example. Which may not correspond with how *you* want it done -- but ASM will always do everything exactly the way you want.

One more: assemblers have almost no bugs, and are very fast to compile code. My OS compiles in under a second. If your C/C++ compiler has a bug in it, you will have introduced an almost-impossible-to-debug systematic error into your kernel/OS. The GNU C 4.2.2 compiler I just downloaded had 200M OF C CODE. Wanna guess if it has some bugs in it?

Reasons to code in some HLL: It's harder to make mistakes in any high-level language. 100 lines of C may code to 500 lines of ASM, and may have (say) 2 bugs in it. Where 500 lines of ASM written by hand will likely have more like 10 or 20 bugs. From my experience, each bug in any language is about equally difficult to find and remove, after the fact.

Also, using any familiar HLL to build your OS will always be faster to code, and may be easily ported to a different platform, if you care about that, as others have said, above.

[Bobalandi]

Gah.. Alright, now I'm confused, so I'm going to map out the pros and cons of what I've gotten (and hopefully will get more) and see which is best for what I want, thanks for all your advice.

[neon]

Neither.

I personally prefer C++ over ASM and C Im not going to point out the pros and cons (As many have already been mentioned here.)

Just use what you are more comfortable with...Dont worry about "Which language is best" because there is none.

[Bobalandi]

I have decided to restart my effort, and use assembly this time, because although I am more used to c and c++, I have found that I could probably get more help with assembly. Thanks for all your help.

[salil_bhagurkar]

If you are not comfortable using C then its probably because you don't understand how C translates into assembly and hence you are not able to understand the abstraction that C has. If you spend some time in the basics of C (forcing yourself out of boredom) then it you should get comfortable in C. You will start finding C close to the power of assembly...

[thegreatseph]

Well, I don't use C I use pascal but, the principle is the same. ASM takes me a long time longer to write in then pascal, and the same will be true with C. However, sometimes compilers write code that is just strange... Get a disassembler and check it out. This is why I still use Turbo Pascal instead of Freepascal.

This is a general example:

HLLs:
+usually quicker to write in
+Usually easier to get others to work on
+More hardware abstraction
+More modular in general (objects, modules, etc)
-Run time libraries usually OS/hardware specific.
-Usually slower, and larger binaries.
-Hardware abstraction can hinder certain tasks.

Asm:
+faster code if you know what you are doing.
+Complete access to memory/resources
+Allows for very small code size
-Long development cycle usually.
-Few people want to work on an all asm project
-Tied intimately to hardware.

Now all of these things are in general. I have yet to find a compiler that I cannot out write for size in asm, not sure about speed as I haven't really researched it. That being said, time is the absolute biggest factor in me not using asm for everything. It takes me longer to write in it than pascal and if I use a asm library it usually diminishes the benefits to writing in asm.

Isn't there a wiki for this?