Thread: C and Assembly

There are some things you simply cannot do in C - for example on the x86 architecture, there are assembler opcodes to load/store the global descriptor table and page tables which simply have no representation in C because they're too hardware-specific. Another example would be handling interrupts - registers must be pushed onto/popped off from the stack in a specific way, and a different instruction is used to return from interrupt handlers ("iret" instead of the normal "ret"). A search for assembler/interrupts/etc. on OSDev might also bring up some other examples.

Apart from the fact that assembler allows exploitation of hardware-specific instructions, and C doesn't, well written assembler can be very highly tuned for performance, and is under explicit control of the programmer - assuming the programmer has a strong understanding of the underlying hardware platform and its instruction set. A good quality compiler can optimise C code, but usually makes some different technical trade-offs than a programmer might choose. Compiler options aren't necessarily enough to overcome that. When the difference in performance - by whatever measure chosen - matters, as it can in core parts of an operating system or in other performance-critical code, then assembler can be the better choice. So it gets used.

Write a bootloader in pure C, then you'll see the problem.

Almost all machines need a different initialisation to get to the point where you can use C's flat memory model, etc., and it's not something that can be done by C alone. Some hardware would need, say, a particular assembly instruction executed while the processor is still in 8086 mode in order to enable memory above 640Kb, for instance. And you can't do that from pure C. And you can't run more pure C code without having done that first.

Almost all the assembly in the Linux kernel is boot code, hardware-specific code (e.g. APIC, interrupts, etc.) or assembly-optimised versions of code (e.g. encryption algorithms) that are proven to be faster than equivalent C where that particular set of instructions are supported (and so you end up with, say, an ARM-optimised version, an MMX-optimised version, an SSE-optimised version, etc. that just replicates some basic C code, all of which are better on the machines that have those instruction sets than the best compiler can achieve from the equivalent C code).

Tell me how you enable access to the entire 8Gb of RAM in a 64-bit x86 machine from pure C code, or how you enable protected mode (x86 processors start up in "real mode", which isn't sufficient to do ANYTHING in nowadays except bootstrap some assembly to get into protected mode - hell, the standard C library probably wouldn't fit into the memory accessible from real mode any more). You can't so such things without bootstrapping and specific assembly aimed at individual computer architectures. And that's where most of the assembly in the Linux kernel lies. That, and hand-optimised routines.