CS 452/652 Winter 2026 - Lecture 5

Multi-Tasking and ARMv8

Jan 20, 2026 prev next

Polling Patterns

• trivial polling loop

  for (;;) {
    if (c1) a1;
    if (c2) a2;
    ...
  }
  

  → worst-case latency: sum of all actions

• higher-frequency input/condition 'c1'

  for (;;) {
    if (c1) a1;
    if (c2) a2;
    if (c1) a1;
    if (c3) a3;
    ...
  }
  

  → worst-case latency: maximum of all actions

• latency still too high? break up action into parts

  for (;;) {
    if (c1) a1;
    if (c2) { a2.1; half-done = TRUE; }
    if (c1) a1;
    if (half-done) { a2.2; half-done = FALSE; }
    ...
  }
  

  → quicky gets complicated and no runtime flexibility

• A0 simple scenario: train important, terminal faster

Multi-Tasking with Preemption

• abstraction for concurreny: natural way of thinking about complicated problems
• asynchronous system implemented via synchronous control flow per task
• runtime/kernel: creates and manages tasks (scheduling and priority)
• automatic suspend/resume facilitated by stack and context switching

Kernel

• uninterruptible (thus predictable) system manager
  • kernel-level vs. user-level execution: hardware modes
  • hardware privilege level: "dangerous" operations possible and permitted
    • central functionality: memory, threading, communication
    • microkernel → device driver logic outside kernel
• task communication: message passing
  • no shared memory; simulated protection
• exceptions: entry/exit between kernel & user-level
  • software interrupt → system call
  • hardware interrupt → from device
• generic kernel loop

  void kmain() {
    initialize();  // includes starting the first user task
    for (;;) {
      currtask = schedule();
      request = activate(currtask);
      handle(request);
    }
  }
  

ARMv8

• RISC - 64-bit memory, but 32-bit instructions: opcode + operands => lots of addressing modes
  • immediate constants with shifting; pc-relative, etc., restricted
  • move, arithmetic, branch, load/store (index and/or increment)
• execution state: 32 vs 64 bit mode (AArch32 vs. AArch64)
• exception level: 0...3 (cf. Intel/AMD "protection ring")
  0: user program
  1: kernel
  2: hypervisor (boot)
  3: secure monitor → example: trust/DRM
• security state: normal (non-secure) vs. secure world
• register file: X0 ... X30=LR, X31=XZR, PC, SP (EL 0-3)
  • program counter, stack pointer (banked: SP_ELx)
• pstate: current processor status (implicit)
  • condition codes (N,Z,C,V), interrupt flags, execution state, exception level
  • Negative, Zero, Carry and oVerflow → conditional branching
• named system registers; access with MRS/read, MSR/save
  • such as: ELR, ESR, SPSR, VBAR
• SP selector (SPSel): use current (banked) SP_ELx or SP_EL0
  • using SP_EL0 in EL1 is simple, but unsafe

Application Binary Interface (ABI)

• subroutine call is a simple context switch (new stack frame)
  • coroutine call is similar to task switch (but deterministic)
• ABI standardized to support separate compilation units
  • some hardware specifications, mostly software/compiler convention
  • stack pointer must be 16-byte aligned
  • important (for us): registers preserved during function call (caller-owned, callee-saved)
• argument passing: registers and stack, stack alignment (16)
  • x0-x7 arguments, return x0/x1 (caller-saved)
  • x8 return ptr (instead of x0) for structs > 16 bytes by value
    • set up by caller, register itself caller-saved
  • x9-x15 local registers (caller-saved)
  • x16,x17 temporary for linker (caller-saved)
  • x18 platform (thread-local storage?) (caller-saved)
  • x19-x28 global registers (callee-saved)
  • x29 frame pointer (callee-saved)
  • x30 link register (return address, callee-saved)
  • condition codes (pstate): undefined on entry/return of subroutine
• floating point operations/registers: do not use or self-study

→ can use ABI rules when implementing (synchronous) system call!

Coding: Mixing C/C++ and Assembler

See various examples file in demo05. Take a look at the compiled .s source

• main.c, adder.c - basic argument passing in x0, x1
• main.c, asm_adder.S - manual assembler routine working with C caller
• adder10.c - passing more than 8 arguments (on stack)
• main3.c, data_adder.c - memory-based data exchange between C and assembler
• asm.c - embed assembler in C code; exchange data with local variables
  special register access: msr/mrs

Recommendations

• use embedded assembler via asm only for short code sequences that do not access stack
• use assembler routine linked as C routine for context-switch code