views:

182

answers:

7

Are cores of OSs (device interaction level) really written in C, or "written in C" means that only most part of OS is written in C and interaction with devices is written in asm?

Why I ask that:

  1. If core is written in asm - it can't be cross-platform.
  2. If it is written is C - I can't imagine how it could be written in C.

OK. And what about I\O exactly - I can't imagine how can interaction with controller HDD or USB controller or some other real stuffs which we should send signals to be written without (or with small amount of) asm. After all, thanks. I'll have a look at some other sources of web.

PS (Flood) It's a pity we have no OS course in university, despite of the fact that MIPT is the Russian twin of MIT, I found that nobody writes OSs like minix here.

+3  A: 

Typically, there's a minimal amount of assembly (since you need some), and the rest is written in C and interfaces with it. You can write functions in assembly and call them from C, so you can encapsulate whatever functionality you want.

By a little implementation-specific trickery, it can be possible to write drivers entirely in C, as it is normally possible to create, say, a volatile int * that will use a memory-mapped device register.

David Thornley
+3  A: 

It depends.

An OS for a small, embedded, device with a simple CPU can be written entirely in C (or C++ for that matter).
For more complicated OS-es, such as current Windows or Linux, it is very likely that there are small parts written in assembly. I would expect them most in the task scheduler, because it has some tricky fiddling to do with special CPU registers and it may need to use some special instructions that the compiler normally does not generate.

Device drivers can, almost always, be written entirely in C.

Bart van Ingen Schenau
"can be written entirely in C" - well, because CPU developers have already written all libraries for you C interface in C with ASM pieces or just only in C? "Device drivers can" - how? I thought, when we, for example, write smt to HDD be mush call instructions that would replace turn inner elements of this HDD in a right way.
MInner
@MInner: Not because CPU developers have provided special libraries, but because the compiler can generate the right code for accessing the device (or the communication bus that the device is connected to)
Bart van Ingen Schenau
Complier for this platform or for any? If for any... Than compiler should be really heavy or me modulated.
MInner
@MInner: A compiler is *always* targeted for a specific (set of related) platforms. You won't be able to take an i386 executable and run it on an ARM processor, but with two appropriate compilers, you *can* create both an i386 executable and an ARM executable from the same source.
Bart van Ingen Schenau
That's my fault - I meant by 'platform' not CPU or something such 'global', but only set of all devices connected to MB. For example, we change USB controller: it seems that we have to signals and etc. code ... Or all USB controllers (because they are USB) and all, for example, IDE HDD has the same 'interface', so we jush configure our compiler for most of such 'standarts'?
MInner
@MInner: Most hardware is connected to standard communication busses, like PCI or I2C, so when replacing one device with another might change things like the address where it can be found or the commands it understands, but it does not change the way the commands are sent to the device. For devices that are meant to be interchangeable, such as HDD, there are higher-level protocols that specify the (minimum set of) commands that you can use.
Bart van Ingen Schenau
I've never found that there is no assembly, even in small embedded systems. The dev enviroment may nicely take care of the little bit of bootstrap asm for you, but it's usually tucked away somewhere.
Digikata
+7  A: 

The basic idea in Unix is to write nearly everything in C. So originally, something like 99% of it was C, it was the point, and the main goal was portability.
So to answer your question, interaction with devices is also written in C, yes. Even very low-level stuff is written in C, especially in Unix. But there are still very little parts written in assembly language. On x86 for example, the boot loader of any OS will include some part in assembler. You may have little parts of device drivers written in assembly language. But it is uncommon, and even when it's done it's typically a very small part of even the lowest-level code. How much exactly depends on implementations. For example, NetBSD can run on dozens of different architectures, so they avoid assembly language at all costs; conversely, Apple doesn't care about portability so a decent part of MacOS libc is written in assembly language.

Jean
Some things have to be written in assembler, at least in certain architectures, like task swapping and so on. But famously, all (AFAIK) of the supposedly low level PCI stuff in NetBSD is written in C.
Amigable Clark Kant
Apple does care about portability. Its current operating system has to run on i386, x86_64 and ARM. The previous iteration (OS X 10.5) also ran on the PowerPC architecture. I doubt if any of its libc is written in assembler except the syscall interface.
JeremyP
Yes, yes they do, but I meant in broad strokes. They support far less hardware configurations than any of their direct concurrents, and in that sense, they have far less portability concerns. About the libc, I haven't seen the sources; I read stuff like strcmp was written in assembler.
Jean
+3  A: 

Some operating systems are written in Assembly language, but it is much more common for a kernel to be written in a high level language such as C for portability. Typically (although this is not always the case), a kernel written in a high level language will also have some small bits of assembly language for items that the compiler cannot express and need to be written in Assembler for some reason. Typical examples are:

  • Certain kernel-mode only instructions to manipulate the MMU or perform other privileged operations cannot be generated by a standard compiler. In this case the code must be written in assembly language.

  • Platform-specific performance optimisations. For example the X64 architecture has an endan-ness swapping instruction and the ARM has a barrel shifter (rotates the word being read by N bits) that can be used on load operations.

  • Assembly 'glue' to interface something that won't play nicely with (for example) C's stack frame structure, data formats or parameter layout conventions.

ConcernedOfTunbridgeWells
+1  A: 

You don't have to wonder about questions like these. Go grab the linux kernel source and look for yourself. Most of the assembly is stored per architecture in the arch directory. It's really not that surprising that the vast majority is in C. The compiler generates native machine code, after all. It doesn't have to be C either. Our embedded kernel at work is written in C++.

Karl Bielefeldt
But it is kind of the point of SO to document all programming facts, simple and complicated alike.
Amigable Clark Kant
+1  A: 

If you are interested in specific pointers, then consider the Linux kernel. The entire software tree is virtually all written in C. The most well-known portion of assembly used in the kernel is entry.S that is specific to each architecture:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/kernel/entry_64.S;h=17be5ec7cbbad332973b6b46a79cdb3db2832f74;hb=HEAD

Additionally, for each architecture, functionality and optimizations that are not possible in C (e.g. spinlocks, atomic operations) may be implemented in assembly:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/include/asm/spinlock.h;h=3089f70c0c52059e569c8745d1dcca089daee8af;hb=HEAD

Noah Watkins