CS 452/652 Winter 2020 - Lecture 5
January 15, 2020
prev next
Kernel Structure
concurrency: asynchronous control flow
- conceptual reasons: divide problem, separation of concerns
- practical reasons: parallel hardware
task: abstraction for concurreny
- multiple tasks
each with synchronous control flow
kernel: creates and manages tasks
- uninterruptible (thus predictable) system manager
- hardware typically supports at least "user" and "system" modes
- "system" mode: with all privileges
→ "dangerous" operations possible
Task
Abstraction
- type / shared: code, readonly data, write-once?
- instance / private: state - read/write data
- primarily on stack
- ok to use static global for singleton tasks with subroutines
State
- management state: Ready, Active, Blocked, etc.
- meta information: parent task
- execution state
- high-level language: line of code, variables
- machine-level: program counter, stack (content, pointer), status register, other registers
Descriptor
- in-kernel data structure hold task state
→ need queues for management
- no heap → use intrusive linkage, i.e., embed 'next' pointer
Execution State
- see ARM Architecure Reference Manual, Sections A1, A2 (showed PDF Pages 29, 41, 43).
- R0-R15 registers
- operands for processor operation
- special purpose: r13/sp (stack pointer), r14/lr (link register), r15/pc (program counter)
- PSR: Processor Status Register
- condition codes (N,Z,C,V)
- interrupt flags
- processor mode
- etc.
- per-mode instances of ('banked') registers, CPSR vs. SPSR
- other instances not directly usable/accessible
- but needed for mode switch (more later)