Courses/Computer Science/CPSC 457.W2012/Lecture Notes/SysArch

Jump to: navigation, search

System Architecture and System Calls

This session will briefly consider a typical hardware environment that an OS is responsible for managing, with a focus on the x86 platform.

We will work from our previous discussion of x86 assembly language programming and see how system calls are made (i.e., their calling convention on x86/Linux), how they are defined, how they can be traced, and how they differ from "normal" function calls.

Focus Questions

  • How does a program become a process (cont.)?
  • How do low-level hardware primitives enable the higher-level resource management and isolation guarantees of an Operating System kernel?


  • Slides from today
  • USRA 2012
  • Encouragement / Laptops
  • "Big" Picture:
    • Userland / Kernel split
    • x86 CPU core architecture, data path, assembly language
    • DPL bits in segment descriptors help label memory pages as belonging to a particular privilege "ring"
  • System Architecture Environment and assembly programming (x86 legacy)
  • examine process creation via fork(2)
  • System Call Invocation
    • We examined how to write a small assembly program that write "hello" to stdout. This involved discovering what the Linux system call invocation convention was
      • eax holds the syscall number, which we can get from unistd.h
      • ebx, ecx, edx, esi, edi hold the system call arguments (either the values or pointers to them, as appropriate -- you can check the manual page for the specific system call to discover the argument types)
      • issue an INT 0x80 instruction; this causes the CPU to generate an interrupt and trap to the OS (via the IDT). The CPU then transitions to supervisor mode (CPL bits set to 00). This is one of the mechanisms that enforce a userspace / kernel split.
  • NASM documentation
  • VDSO note / sidebar (i.e., how system calls are really invoked)


  • None - catch up on previous reading or svn tutorial material.

Background / Reference