Linked by Hadrien Grasland on Fri 28th Jan 2011 20:37 UTC
OSNews, Generic OSes It's recently been a year since I started working on my pet OS project, and I often end up looking backwards at what I have done, wondering what made things difficult in the beginning. One of my conclusions is that while there's a lot of documentation on OS development from a technical point of view, more should be written about the project management aspect of it. Namely, how to go from a blurry "I want to code an OS" vision to either a precise vision of what you want to achieve, or the decision to stop following this path before you hit a wall. This article series aims at putting those interested in hobby OS development on the right track, while keeping this aspect of things in mind.
Thread beginning with comment 460188
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Machine language or C
by Morin on Sat 29th Jan 2011 20:25 UTC in reply to "RE[3]: Machine language or C"
Member since:

I was wondering whether a hardware driver in machine language is more easy to add to your kernel and more universal then say a higher level language driver. But maybe then you would have less functionality?

No. As neolander said, you can wrap machine language instructions in C functions (or Java methods, or anything else that models a procedural construct).

The only area where this is impossible is when the function call itself interferes with the purpose of the instruction, and this occurs in very very few places. Certainly not hardware drivers, but rather user-to-kernel switching, interrupt entry points, etc.

As a side node, the NT kernel is based on an even more low-level core called "HAL" (hardware abstraction layer) that IIRC encapsulates those few places where you actually NEED machine language.

Reply Parent Score: 2

RE[5]: Machine language or C
by Neolander on Sat 29th Jan 2011 22:32 in reply to "RE[4]: Machine language or C"
Neolander Member since:

I'd also add that in some cases, there's so much assembly in functions that devs are better off writing the whole function in assembly instead of using such wrappers.

x86 examples :
-Checking if CPUID is available
-Switching to long mode (64-bit mode) or to its "compatibility" 32-bit subset.

Edited 2011-01-29 22:33 UTC

Reply Parent Score: 1