Bobalandi wrote:
Dex wrote:
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.