Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Without being presumptuous, I would like you to consider the possibility of this. Most OS today are based on pretty low level languages (mainly C/C++) Even the new ones such as Android uses JNI & underlying implementation is in C

In fact, (this is a personal observation) many programs written in C run a lot faster than their high level counterparts (eg: Transmission (a bittorrent client on Ubuntu) is a whole lot faster than Vuze(Java) or Deluge(Python)). Even python compilers are written in C, although PyPy is an exception.

So is there a particular reason for this? Why is it that all our so called "High Level Languages" with the great "OOP" concepts can't be used in making a solid OS?

So I have 2 questions basically.

  1. Why are applications written in low level languages more efficient than their HLL counterparts? Do low level languages perform better for the simple reason that they are low level and are translated to machine code easier?
  2. Why do we not have a full fledged OS based entirely on a High Level Language?
share|improve this question
29  
You imply that only "High Level Languages" are object oriented, which is not true. –  Uooo Jun 28 '13 at 7:59
2  
@rtindru "Pretty low-level language" (mainly C/C++)? What is your definition of High-Level Language then? You need to be clear about your definition/interpretation of High-Level Language. Python is actually a scripting language as it gets executed directly on its engine (IDLE or command line terminal), if you did not realise that by now. There is a very good reason (philosophical and practical) why C/C++ are used as implementation languages for lots of OS, but I am sure the power users here will probably not be jumping into that for this question. –  hagubear Jun 28 '13 at 8:38
8  
Android is not a brand new OS. It's just another Linux flavour. –  Den Jun 28 '13 at 8:45
3  
@hagubear There is a very good reason (philosophical and practical) why C/C++ are used as implementation languages for lots of OS. What is this very good reason? –  rtindru Jun 28 '13 at 9:30
2  
If I understand correctly, the OS for LISP machines were written in LISP. Though perhaps it could be argued that the dialect used was a low-level language? –  Robert Fisher Jun 28 '13 at 13:39

9 Answers 9

up vote 34 down vote accepted

Microsoft has done some very interesting research in this direction, if you look into Singularity:

http://research.microsoft.com/en-us/projects/singularity/

Also, Mothy Roscoe et al have been working on Barrelfish which uses the Eclipse constraint programming language as an OS service to sort out all kinds of OS management and resource allocation problems:

http://www.barrelfish.org/

share|improve this answer
    
Wow, I can't vote up, need 15 reps... just joined today! Thanks a lot. –  rtindru Jun 28 '13 at 7:55
9  
@rtindru: even with 1 rep point you can accept an answer What does it mean when an answer is "accepted"? –  Marjan Venema Jun 28 '13 at 11:01
6  
Accepting an answer tends to cut down on new answers/discussion. Personally, I would recommend against accepting (to this specific question) for at least another day. –  Brian Jun 28 '13 at 16:02
1  
I would add Cosmos to the bunch: open source, third party, not as interesting as singularity but have some nice ideas! cosmos.codeplex.com –  Lorenzo Dematté Jul 5 '13 at 7:17

A lot depends on where you put the division between low-level and high-level languages. For example, different people tend to put a language like C++ on different sides of that divide.

Regarding your questions:

  1. I don't believe there is such a difference between low-level and high-level languages, but more a difference between interpreted languages and languages that compile to native instructions.

    But there might also be a difference in culture between programmers, where the once that use a low level language focus more on the performance aspects of the (design) choices they make.

  2. If you consider C++ to be high-level, then there is at least one OS written entirely in a high-level language (Symbian OS is written in C++). What stops you from writing an OS in most high-level languages are two things:

    • An OS needs low-level access to memory and hardware and perform dirty tricks on them. This kind of access is generally considered unsafe for application-level programs, so many high-level languages don't allow it.
    • An OS needs to execute without support software being present, such as interpreters. This makes it extremely hard to write an OS in a language that can't easily be compiled into native instructions.
share|improve this answer
25  
There is no such thing as an interpreted language or a language that compiles to native instructions. A language is a set of mathematical rules, it is neither interpreted nor compiled, it just is. Interp. and Comp. are traits of, well, the interpreter or the compiler, not the language. Every language can be implemented using a compiler or an interpreter. Most languages today have both interpreted and compiled implementations. There are interpreters for C and all major JavaScript implementations compile to native code. And what is native code anyway? If I compile Java to JVM bytecode and run –  Jörg W Mittag Jun 28 '13 at 10:53
9  
that on a Java CPU, and I compile C to ARM machine code and run that on an ARM interpreter because my PC doesn't have an ARM CPU, then what makes ARM native and JVML not? –  Jörg W Mittag Jun 28 '13 at 10:53
3  
@JörgWMittag: If you have a CPU that can directly execute Java bytecode (without using an additional JVM), then Java bytecode is native code for that CPU. Also, I don't rule out the possibility of writing an OS in a language that is typically interpreted or executed in a VM, but it does make them less obvious choices. –  Bart van Ingen Schenau Jun 28 '13 at 11:58
11  
@JörgWMittag - I agree that any language can be compiled or interpreted (compile a bash script; use interpreted C++ (CINT/Cling)), but many decisions in language design are based on will this be interpreted, compiled, or both. A language that makes you manually declare/initialize statically-typed variables, manually allocate/free memory, do pointer arithmetic, remember to check array bounds will be less convenient in an interpreter (versus a language that garbage-collects memory, infers dynamic type, checks array bounds). Is this line 100% clear? No, but the difference exists in practice. –  dr jimbob Jun 28 '13 at 20:30

A main reason for the dominance of C for operating systems lies in history - current mainstream operating systems like Windows and all forms of Unix (BSD, Solaris, HP-UX, MacOS X, ... as well as clones like Linux) go back a long time, before OO and other "high level" constructs became mainstream.

For the core of the operating system besides performance there are needs to e very specific about the hardware instructions and one needs full control over memory which languages like C do very well.

For embedded systems there sometimes are operating systems using higher level languages for greater parts of the system. One notable example is JavaOS by Sun.

For widespread operating systems an notable example not using C also is the classic MacOS before MacOS X - that was in large parts written in a dialect of Pascal which allowed some form of object orientation.

share|improve this answer

First, there are some bootstrap issues. Most of the features that make high level languages easier are based on abstractions that a kernel must provide itself. How do you write a memory manager in a language that requires a memory manager? How do you write I/O drivers without using the nice I/O standard libraries of your language? How do you create threading and synchronization primitives without using the language's libraries?

Second, it's extremely useful and much more readable when writing operating systems to be able to assign a variable to a specific memory location. This is easy in C, and every single C programmer knows how to do it. If it's even possible in higher level languages, it's so rare that only gurus know how to do it.

In other words, when you account for all the limitations and modifications you would have to accept, C and C++ start looking a lot easier.

share|improve this answer
2  
Your first paragraph makes no sense. An I/O driver in C doesn't use stdio.h either. A custom mutex implementation doesn't use pthreads. That's precisely what it means to implement it yourself! And that is independent of the language you're using. That is not to say high level languages are a good choice for low level tasks (they usually aren't in my experience). –  delnan Jun 28 '13 at 16:12
    
I'm aware of that. I'm just pointing out that a lot of what differentiates a high level from a low level language is in those parts of the language that are unavailable in kernel development. When you compare languages core to core, C doesn't look so spartan any more. –  Karl Bielefeldt Jun 28 '13 at 16:21
    
Not quite true. While you'll need some code that doesn't use X to implement X, all remaining code can depend on that code and use X. –  delnan Jun 28 '13 at 16:28
    
That's a good point. –  Karl Bielefeldt Jun 28 '13 at 16:33

There are a number of good reasons for this.

Today's low-level language was yesterday's high-level language

Yes, believe it or not, once upon a time even C was viewed as a high-level language. Even ~20 years ago it was common enough to see it described as a "mid-level" language. This was a time before OO was as popular as it is today, Java didn't exist, C# didn't exist, even C++ wasn't properly standardized yet.

Historical Inertia

Operating systems that you use today have deep deep roots in history. Windows goes back to the early/mid 80s, Unix goes back to the early/mid 70s. There is a LOT of old, working code in operating systems, and you generally don't want to rewrite old, working code.

At some point you have to go down to the hardware

This happens in the kernel, it happens in drivers, it happens in memory management subsystems, it happens in the filesystem. Sure you can layer a high-level language on top of it, but you still need the ability to more directly access the hardware that a lower-level language offers.

Portability

I don't mean portability to different hardware or a different OS as it's more commonly understood today; this is more subtle. There is one major advantage of providing a C-based interface for something, and that is the fact that virtually every other language that exists can link to C. Even the Windows API is still a C-based API these days for that reason.

Personal Preference

Some people just prefer to program this way, and that can be a major factor. For example, Linus Torvalds has a famous rant against C++ which makes it pretty clear that as far as he's concerned, C will always be his tool of choice for this kind of work (the content of the rant and whether or not you agree with it is irrelevant to this discussion; the fact that the rant exists is enough).

Taken together, these should clearly establish why an operating system was originally written in something like C back in the old days, and why very significant chunks of it - even today - remain so.

share|improve this answer
    
+1 for the first two points! –  Lorenzo Dematté Jul 5 '13 at 7:09

First of all, bootstrapping requires at least a small part to be written in Assembly or equivalent.

Second, there was a OS written in an indisputably HLL - Lisp Machine. (The fact that it failed commercially had more to do with other hardware becoming cheaper faster and the triumph of Worse is Better than with deficiencies of its philosophy or design).

Third, C++ is quite object-oriented and high level, so, as others pointed out, Symbian OS is another example.

Fourth, there is little need for new OSes at this time. We already have quite a few linux and bsd flavors which run on just about any hardware, and creating a brand new OS from scratch is quite expensive.

share|improve this answer
    
You missed the Burroughs B5000 mainframes. Their operating system was written in Burroughs Extended ALGOL. –  John R. Strohm Jul 2 '13 at 15:21
1  
there is little need for new OSes at this time I have still not decided myself if this is true or not.. Yes, modern OSes (modern windows (NT) / modern Unix) are all we need, functionality and performance wise. But barely: they are born in another area where "the net" was corporate/university and the users trusted, and multiproc was 2/4 processors. They are "plagued", to some degrees, by the excess of trust (rootkits, malware, viruses..). I am starting to think that there IS space for a modern, safe, isolated OS ... with better support for parallelism too (better then threads) –  Lorenzo Dematté Jul 5 '13 at 7:14

Most of the higher-level languages that you mention have a feature that doesn't fit well with operating systems: Automatic memory management. You can't rely on a garbage collector when writing a real-time system -- either soft (which is what an operating system is) or even worst hard. To quote Tanenbaum [i]:

Some things that C does not have include built-in strings, threads, packages, classes, objects, type safety, and garbage collection. The last one is a show stopper for operating systems. All storage in C is either static or explicitly allocated and released by the programmer, usually with the library function malloc and free. It is the latter property -- total programmer control over memory -- along with explicit pointers that makes C attractive for writing operating systems. Operating systems are basically real-time systems to some extent, even general purpose ones. When an interrupt occurs, the operating system may have only a few microseconds to perform some action or lose critical information. Having the garbage collection kick in at an arbitrary moment is intolerable.

Now, you might argue that C++ is also a good candidate since it offers manual memory management. C++ has already been used in some operating systems such as Symbian (mentioned by Bart) and BeOS. But IMHO C is still the fastest language that can be ported in many architectures without a huge effort (in contrast to assembly of a specific architecture).

[i]: Modern Operating Systems 3rd edition, page 73

share|improve this answer
2  
Symbolics machines had automatic memory management. Smalltalk did on an Alto. That was in the 80s. A linear type system removes the necessity for GC completely. These are solved problems, if only we could remember that! –  Frank Shearar Jul 3 '13 at 19:52
    
It would be possible for a language to include automatic memory management, but include a special kind of "deeply-pinned" reference and allow methods to explicitly declare that they will not access any non-pinned reference nor invoke any methods that might do so. There would be no need for a stop-the-world garbage collector to interfere with code running in a method which was not going to access any objects that might be modified by the GC. –  supercat Jun 12 at 16:17

To better phase what I wrote previously.

The Burroughs 5xxx - 6xxx machines did not have an assembly language. The lowest language available was an extension to Algol. The Algol was implemented in hardware. The OS and all languages were written in Algol. It outperformed all the competitor machines of the time. It also required significantly less code which made it much easier to maintain. It had stack hardware which supported a recursive language such a Algol.

The Burroughs operating system evolved into a version called MCP. MCP currently runs on Unisys systems.

share|improve this answer

As others have pointed out, several operating systems have been written in high level languages. Perhaps what you mean is that all the successful, mass market, general purpose OS have been written in some combination of assembly, C, and C++?

Most high level languages have tons of helpful features that carry an associated performance cost. Automated memory management is an obvious example, bounds checking of arrays is another. If you are writing a general purpose OS you are likely to run into situations where the performance penalty of these helpful features is more than you are willing to pay. At that point you'd like to be able to turn them off. Languages like Python, C#, and Java vary in which features you can turn off, but none of them are as versatile as C or C++ in this regard.

In this aspect C and C++ are almost as versatile as pure assembly. If you decide that you need ten different memory managers covering ten different memory allocation scenarios you can implement them all in C and C++, and load and unload them as you see fit. Heck, you don't even have to link to the standard C runtime libraries or startup code if you don't want to.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.