How can assembly work on an Operating System?

Question

if the kernel takes control of the system, how can assembly language work?

Assembly language is introduced as a collection of mnemonics that a computer "understands" and various macros to make certain tasks easier.

How can assembly control the CPU and memory if it cannot do that without making requests to the operating system?

For instance, if I want to do instruction mov ax, #4, wouldn't I need my program to send requests to the OS in order to be able to do so?

I'm really curious...

Thanks!

Answer 1

The CPU has mechanisms which assist the OS in protecting resources. Let's use your example of an x86-chip. The "general-purpose" registers, such as eax, are not protected. But the debug registers, such as DR0, are.

When the OS is running, the CPU is executing in "ring 0" or what people call "system mode" to use a generic term. The programs are running "ring 3" on x86, or what people call "user mode."

When the execution changes from ring 3 to ring 0 (more on how that is done later), the CPU drops the protections of user mode. This is what allows the OS to change the debug registers.

However, the main thing protected by the OS are memory locations and device input/output. For this reason, the in and out instructions are privileged, and may not be executed at ring 3. Other privileged instructions include mov to/from control registers.

Memory is protected via the TLB, which is also used to define Virtual Memory (VM) address rangers visible to the user mode processes. It is this table which controls the memory space visible to each process. The TLB caches the page tables, which are stored in memory which only the ring 0 operating system may modify. Similarly, the interrupt vectors and any memory-mapped devices are allocated to memory ranges that only the OS may access. (An OS could map those pages into user-space processes, but that would potentially let user-space take over the machine.)

When you execute, e.g., mov [eax], edx, the address referenced by eax is looked up in the TLBs. The CPU determines from the access bits in the TLB whether the instruction is legally accessing memory. (These come from the page table entry, e.g. the R/W bit needs to be set to allow that store to memory to run. Otherwise it will raise a #PF page fault exception which the OS can catch. And handle by doing copy-on-write and returning to user-space to rerun the instruction: soft page fault. Or deciding that it's user-space's fault (invalid page fault) and sending a SIGSEGV signal, terminating the process with a segmentation fault. Or whatever terminology the OS wants to use, if not Unix.)

When processes are swapped by the OS scheduler, the general-purpose registers such eax are saved in a per-thread memory area maintained by the OS. The thread being switched to is restored from its memory image of previous register values.

The computer would be incredibly slow if the OS interfered with every machine instruction. In particular, access to general registers should be maintained as fast as possible. The TLB look-ups for memory accesses are cached and not slower than the memory access itself.

To switch from ring 3 to ring 0, a software interrupt is generated. This is the "system call" interrupt. Interrupts run at ring 0, and are configured before the first process begins, by the OS. The system call interrupt transfers control to the OS code. When execution returns from the interrupt service routine, the CPU is returned to ring 3.