CS452 - Real-Time Programming - Fall 2008

Lecture 7 - Architecture

Questions & Comments

Kernel: Part 1

Primitives to Implement

Test Program

Hardware Facts for Eos

Memory Map

Note. x and y could be numbers above F


Accessed by special I/O instructions

Architecture of X86

General Purpose Registers (all 32-bit)

All these registers have special names for the low 16 bits. (drop the E), and for the low 8 bits (add an L), and for the second 8 bits (add an H)

Special Purpose Registers

  1. IDTR: interrupt descriptor table register

    ID: interrupt descriptor


  2. GDTR: global descriptor table

    GD: global descriptor, describes a memory segment

    There is no GDT in place when the kernel boots


  3. CS, DS, ES, FS, GS, SS: segment registers
  4. EIP: program counter

Addressing Memory

Physical address is

Helps to provide

  1. position independent (relocatable) code
  2. memory protection

Six segment registers

  1. CS
  2. DS
  3. ES
  4. FS
  5. GS
  6. SS

Each segment register is an index into a Global Descriptor Table (GDT), which contains

Index is actually contents of register >> 3.

Setting up a Task

Every task requires at least two GDTs

The compiler assumes that DS = SS

Set DS = ES = FS = GS = SS for each task

There is no GDT in place when the kernel boots

How is this done

  1. The address of the table is kept in the special register GDTR
  2. lgdt sets GDTR; sgdt reads GDTR

Yet another register EFLAGS contains processor state such as

Setting up a task

Getting the Kernel Started

Each task is a C function

So is the kernel

Each gets compiled and linked into an ELF executable

Then 452-post.py (/u/cs452/public/tools/bin/452-post.py) binds the ELFs together to be downloaded.


Before starting to execute the kernel needs to have

  1. A stack, on which it can place data, with the stack pointer set.
  2. Its first instruction in the PC

The boot loader does this. How?

  1. The bound executable obeys the multiboot specification
  2. The kernel is called by int main( unsigned long magic, multiboot_info_t *mbiaddr )
  3. The stack starts as mbiaddr, magic
  4. multiboot_info_t is a struct with the following interesting fields
    typedef struct multiboot_info {
      unsigned long mods_count;
      unsigned long mods_addr;
    } multiboot_info_t

    The second is a pointer to module_t, the first module record.

  5. module_t is a struct with the following interesting fields
    typedef struct module {
      unsigned long mod_start;
      unsigned long mod_end;
      unsigned long string;
    } module_t

You might find this URL has some interesting information (and links) if you are really interested in how executables are structured, or in the multiboot boot process.

Return to: