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 460177
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Machine language or C
by WereCatf on Sat 29th Jan 2011 17:47 UTC in reply to "RE: Machine language or C"
WereCatf
Member since:
2006-02-15

I'd strongly advise against assembly: unless you have years and years of experience with it you'll sooner or later simply lose oversight of the whole thing simply due to the sheer amount of text you'll be writing. Not to mention how incredibly tedious it is.

Of course it's a way of learning assembly, yes, but there's plenty of better ways of going about that one. If you plan to also learn kernel programming at the same time then you're faced with the famous chicken and egg problem: you need to learn assembly to do kernel coding, and you need kernel coding to learn assembly..

Of course opinions are opinions, but I'd much rather suggest to set out to learn one thing at a time: either assembly, or kernel programming, not both. If you wish to do kernel programming then choose a language you're more familiar with.

Reply Parent Score: 2

RE[3]: Machine language or C
by fran on Sat 29th Jan 2011 18:53 in reply to "RE[2]: Machine language or C"
fran Member since:
2010-08-06

About keeping track of hardware changes.
The main reason SkyOS became dormant is the rapid development of hardware
http://www.skyos.org/?q=node/647

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?

Reply Parent Score: 2

RE[4]: Machine language or C
by Neolander on Sat 29th Jan 2011 19:58 in reply to "RE[3]: Machine language or C"
Neolander Member since:
2010-03-08

Not necessarily. You can create wrappers in order to use the arch-specific assembly functions you need in your language of choice, and keep all the logic written in this language.

As an example, if I need to output bytes on one of the ports of my x86 CPU, all I have to do is to create a "C version" of the OUTB assembly instruction, using macros and inline assembly, and after that I can use it in the middle of my C code at native speed.

With GCC's inline assembly, it'd look something like this :
"#define outb(value, port) \
__asm__ volatile ( \
"outb %b0,%w1" \
::"a" (value),"Nd" (port) \
)"

Yes, it's ugly, but you only have to do it once.

Edited 2011-01-29 20:09 UTC

Reply Parent Score: 1

RE[4]: Machine language or C
by Alfman on Sat 29th Jan 2011 20:22 in reply to "RE[3]: Machine language or C"
Alfman Member since:
2011-01-28

The majority should definitely be coded in a high level language.

In the days of DOS TSRs, we wrote in assembly because the code had to be small and efficient.

Even to this day it's often easy to beat a compiler's output simply because it is restrained by a fixed calling convention. In x86 assembly language, I am free to stuff values where I please. A variable can be stuffed into segment registers, a function returning boolean can use the "zero flag". This eliminates the need to do "cmp" in the calling function.

In my own assembly, I can keep variables intact across function calls without touching the stack. To my knowledge, all C compilers use unoptimized calling conventions by design so that separately compiled object files link correctly.

Of course above I'm assuming that function call overhead is significant, YMMV.


However, all this optimization aside, looking back on TSRs I wrote, it takes a long time to familiarize oneself with code paths again. This is true of HLL too, but even more so with assembly. It is crucial to comment everything in assembly, and it is equally crucial that the comments be accurate.

Low level assembly is just not suitable for code that is meant to developed over time by many people. Besides, it's not portable, and cannot benefit from new architectures with a simple recompile.

Off the top of my head, the bootloader and protected mode task management are the only things which really require any significant assembly language.

Reply Parent Score: 1

RE[4]: Machine language or C
by Morin on Sat 29th Jan 2011 20:25 in reply to "RE[3]: Machine language or C"
Morin Member since:
2005-12-31

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