OSDev.org

I have been trying to create a OS in assembly, which I could get SOME done, but not absolutely what I wanted. So, for a beginner OS developer, What language is best.

... Whatever language you like to use that allows low level access...?

C is relatively easy to set up. I recommend it, for its beginner friendliness. (Although I use C++.)

Languages
That said, the easiest is C, just because so much sample code is in C (and it was designed for this kind of work)

crossey wrote:I have been trying to create a OS in assembly, which I could get SOME done, but not absolutely what I wanted. So, for a beginner OS developer, What language is best.

I'd start with C - it has minimal setup requirements, most of the sample code is written in it, and most OSes are written in it too.

Other languages such as C++, Pascal, Ada, Objective-C are possible, but require more setup and more initial investment to get them off the ground, which is generally only worth it if you think you know enough about that language that you're going to get something useful out of it.

C++ is very backwards compatible with C, and its setup costs are nil if you stay away from a couple features (global variables with constructor, exceptions, RTTI). It gives you several benefits over plain C - better scope, types, templates, etc. Even if you're just "writing C in C++" it's a good idea, IMO.

JamesM wrote: Other languages such as C++, Pascal, Ada, Objective-C are possible, but require more setup and more initial investment to get them off the ground, which is generally only worth it if you think you know enough about that language that you're going to get something useful out of it.

Objective-C requires a runtime, doesn't it? That would mean that you already need a kernel in some other language to use it.

Yargh wrote:

JamesM wrote: Other languages such as C++, Pascal, Ada, Objective-C are possible, but require more setup and more initial investment to get them off the ground, which is generally only worth it if you think you know enough about that language that you're going to get something useful out of it.

Objective-C requires a runtime, doesn't it? That would mean that you already need a kernel in some other language to use it.

Requiring a runtime does not require an existing kernel; you could quite easily develop an Obj-C runtime to run on bare metal. Whether it would be a good idea or not is another matter (And I expect it would prove difficult to optimize your bare-metal runtime in the same ways as user-space runtimes are)

Assembly is best, of course. Some less important and complex drivers could be in C/C++, but nothing critical should be.

rdos wrote:Assembly is best, of course. Some less important and complex drivers could be in C/C++, but nothing critical should be.

Yes, because you're better than an optimizing and auto-vectorising compiler.

****.

You can do everything in Assembler, the question is whether you'd want to. I know we have a couple of die-hard evangelists here, but the simple matter of fact is that ASM is outside the "sweet spot" of effort-vs-benefit when used for the whole of a large-scale project like an OS kernel. Having parts in ASM is quite obviously not only acceptable but required. But deciding on ASM as language-of-choice for a desktop OS project begun today, is about as "insane" as e.g. Java on the other side of the pond. While not getting you a place in the asylum outright, it's quite the initial suspicion. [1]

C is probably the most well-suited language for kernel work, combining close-to-the-metal functionality as well as high-level language primitives. It's also very, very well understood and documented.

C++ comes a very close second - as Rusky correctly pointed out, initially it can easily and painlessly be pared down to zero runtime requirements; those requirements can be satisfied retro-actively with little effort; it allows the same close-to-the-metal coding as C does; and it provides even higher-level primitives that make maintenance of a large code base (like a kernel) easier. It, too, is well understood and documented, and few people (outside the LKML) will look askance at you for using it in kernel space. It allows to hide complexity behind beautifully simple interfaces. The downside is that C++ makes it somewhat easier to write code that looks simple but is quite inefficient. This can easily be avoided by programmers of appropriate skill, but it takes some discipline and attention, while C requires more ineptitude (or mallice) to screw up in this regard.

Then there's a gap until the next-best contenders show up on the map. There is invariably some involved tinkering required to satisfy their runtime requirements in kernel space, and they are rather "esoteric" choices for kernel work (at least when compared to C/C++). I would list Obj-C and Pascal in this area; I don't know enough about ADA to list it or not. There's always the Singularity project popping up in discussion at this point, as proof-of-concept that one could code in C#, but I don't have read enough on that either to judge. The WP site lists ASM, C, C++, C# and Sing# as languages, so I assume the "tinkering required" is quite involved, and I don't see much (if any) benefit in C# compared to C++ in this area, but YMMV.

(On second thought, this group of languages is "somewhat esoteric" for any kind of software work. )

Then there's another, larger gap before we come to the languages that might be possible, but are clearly inappropriate for kernel work because they combine prohibitive runtime requirements with no technical advantage whatsoever. Java or VisualBasic have to be listed here - languages aimed at RAD-style coding, the yearning for which usually betrays a programmer who would like the bragging rights of OS development, but is afraid to touch a pointer with ten-foot pliers because he heard they are evil (or actually learn a second programming language after he payed so much for that distance-learning "Java in 21 days" course).

Then another gap until we get to the "ridiculous" section, like JavaScript or XML.


[1]: To clarify. I don't doubt there are people out there who can, with intense care, discipline, and outrageous skill, write ASM code that outperforms optimized compiler output for a specific CPU. I know a couple of them myself. But such people are few, people capable of maintaining such code are even fewer, and the effort required to write (or maintain) ASM code at this level is quite intense. And with the next generation of the CPU (or the compiler...), your ASM code might again be outperformed by generic C. Outside the critical path, I say the benefit is simply not worth the effort. Even inside the critical path, I would always write the code in C/C++ first to see what the compiler makes of it, and to benchmark my ASM code against it (automatically, so I can test and re-test my code against later CPUs and compiler versions). ASM has its niche, in which it shines, but outside that niche it's just as outclassed as any other language outside its niche.

I don't claim to know all languages. (And I couldn't tell what Modula-2 source looks like to save my life.)

Consider the languages named in my "categories" to be examples only, with no claim for completeness or exclusiveness.

PS: What Modula-2 might save in runtime requirements, it seems to add in esoteric-ness.

JamesM wrote:

rdos wrote:Assembly is best, of course. Some less important and complex drivers could be in C/C++, but nothing critical should be.

Yes, because you're better than an optimizing and auto-vectorising compiler.

****.

Of course. Vectorising or not, C-compilers simple cannot handle global optimizations (like automatic register allocation between functions) very well, and therefore will suck at function-call performance. And even if they have an automatic register allocation scheme, these are bound to be less than optimal, requiring shuffling things between memory/stack/registers. I clearly can see the difference (in performance) between my old call interface that used stack for parameters, and needed an intermediate step, with the new fine-tuned interface that tells the compiler exactly which registers to pass parameters in. Additionally, C compilers also suck when there is more than one out-parameter, as these need to be passed as pointers. With an assembly-interface, they would be passed in registers.

Not to speak of the fact that C compilers really suck at handling segmented memory-models.

EDIT: Forgot to mention that C cannot handle using the CY flag to signal return status. This is clearly superior to using a whole return-register for status (especially when combined with ordinary results which then needs to be passed by reference).

These problems are built-into C, and thus cannot be solved with any kind of optimizations available.

I'd really like to see a non-trivial, non-biased piece of your code benchmarked against compiled C/C++. The proof is in the eating, you know...

Solar wrote:I'd really like to see a non-trivial, non-biased piece of your code benchmarked against compiled C/C++. The proof is in the eating, you know...

Not easy to do. First, most compilers would lose on walk-over as they cannot generate segmented code, and secondly, those that could would lose because they cannot handle minimizing segment register reloads, and optimize segment register usage.

And comparing flat-memory model code with segmented code is not valid.

Another issue is that optimization works best on long procedures, but it is generally good programming practise to keep procedures short, which leads to less local optimizations.