From f53494c28e362fb7752bbc83417b9ba47cff0bf5 Mon Sep 17 00:00:00 2001 From: rsc Date: Wed, 3 Sep 2008 04:50:04 +0000 Subject: DO NOT MAIL: xv6 web pages --- web/l2.html | 494 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 494 insertions(+) create mode 100644 web/l2.html (limited to 'web/l2.html') diff --git a/web/l2.html b/web/l2.html new file mode 100644 index 0000000..e183d5a --- /dev/null +++ b/web/l2.html @@ -0,0 +1,494 @@ + + +L2 + + + +

6.828 Lecture Notes: x86 and PC architecture

+ +

Outline

PC architecture +
x86 instruction set +
gcc calling conventions +
PC emulation +

+ +

PC architecture

+ +

A full PC has: +
- an x86 CPU with registers, execution unit, and memory management +
- CPU chip pins include address and data signals +
- memory +
- disk +
- keyboard +
- display +
- other resources: BIOS ROM, clock, ... +
+ +
We will start with the original 16-bit 8086 CPU (1978) +
CPU runs instructions: +
```
+for(;;){
+	run next instruction
+}
+
```
+ +
Needs work space: registers +
- four 16-bit data registers: AX, CX, DX, BX +
- each in two 8-bit halves, e.g. AH and AL +
- very fast, very few +
+
More work space: memory +
- CPU sends out address on address lines (wires, one bit per wire) +
- Data comes back on data lines +
- or data is written to data lines +
+ +
Add address registers: pointers into memory +
- SP - stack pointer +
- BP - frame base pointer +
- SI - source index +
- DI - destination index +
+ +
Instructions are in memory too! +
- IP - instruction pointer (PC on PDP-11, everything else) +
- increment after running each instruction +
- can be modified by CALL, RET, JMP, conditional jumps +
+ +
Want conditional jumps +
- FLAGS - various condition codes +
  - whether last arithmetic operation overflowed +
  - ... was positive/negative +
  - ... was [not] zero +
  - ... carry/borrow on add/subtract +
  - ... overflow +
  - ... etc. +
  - whether interrupts are enabled +
  - direction of data copy instructions +
  +
- JP, JN, J[N]Z, J[N]C, J[N]O ... +
+ +
Still not interesting - need I/O to interact with outside world +
- Original PC architecture: use dedicated I/O space +
  - Works same as memory accesses but set I/O signal +
  - Only 1024 I/O addresses +
  - Example: write a byte to line printer: +
```
+#define DATA_PORT    0x378
+#define STATUS_PORT  0x379
+#define   BUSY 0x80
+#define CONTROL_PORT 0x37A
+#define   STROBE 0x01
+void
+lpt_putc(int c)
+{
+  /* wait for printer to consume previous byte */
+  while((inb(STATUS_PORT) & BUSY) == 0)
+    ;
+
+  /* put the byte on the parallel lines */
+  outb(DATA_PORT, c);
+
+  /* tell the printer to look at the data */
+  outb(CONTROL_PORT, STROBE);
+  outb(CONTROL_PORT, 0);
+}
++		
```
  + +
- Memory-Mapped I/O +
  - Use normal physical memory addresses +
    - Gets around limited size of I/O address space +
    - No need for special instructions +
    - System controller routes to appropriate device +
    +
  - Works like ``magic'' memory: +
    - Addressed and accessed like memory, + but ... +
    - ... does not behave like memory! +
    - Reads and writes can have ``side effects'' +
    - Read results can change due to external events +
    +
  +
+ + +
What if we want to use more than 2^16 bytes of memory? +
- 8086 has 20-bit physical addresses, can have 1 Meg RAM +
- each segment is a 2^16 byte window into physical memory +
- virtual to physical translation: pa = va + seg*16 +
- the segment is usually implicit, from a segment register +
- CS - code segment (for fetches via IP) +
- SS - stack segment (for load/store via SP and BP) +
- DS - data segment (for load/store via other registers) +
- ES - another data segment (destination for string operations) +
- tricky: can't use the 16-bit address of a stack variable as a pointer +
- but a far pointer includes full segment:offset (16 + 16 bits) +
+ +
But 8086's 16-bit addresses and data were still painfully small +
- 80386 added support for 32-bit data and addresses (1985) +
- boots in 16-bit mode, boot.S switches to 32-bit mode +
- registers are 32 bits wide, called EAX rather than AX +
- operands and addresses are also 32 bits, e.g. ADD does 32-bit arithmetic +
- prefix 0x66 gets you 16-bit mode: MOVW is really 0x66 MOVW +
- the .code32 in boot.S tells assembler to generate 0x66 for e.g. MOVW +
- 80386 also changed segments and added paged memory... +
+ +

+ +

x86 Physical Memory Map

+ +

The physical address space mostly looks like ordinary RAM +
Except some low-memory addresses actually refer to other things +
Writes to VGA memory appear on the screen +
Reset or power-on jumps to ROM at 0x000ffff0 +

+ +

++------------------+  <- 0xFFFFFFFF (4GB)
+|      32-bit      |
+|  memory mapped   |
+|     devices      |
+|                  |
+/\/\/\/\/\/\/\/\/\/\
+
+/\/\/\/\/\/\/\/\/\/\
+|                  |
+|      Unused      |
+|                  |
++------------------+  <- depends on amount of RAM
+|                  |
+|                  |
+| Extended Memory  |
+|                  |
+|                  |
++------------------+  <- 0x00100000 (1MB)
+|     BIOS ROM     |
++------------------+  <- 0x000F0000 (960KB)
+|  16-bit devices, |
+|  expansion ROMs  |
++------------------+  <- 0x000C0000 (768KB)
+|   VGA Display    |
++------------------+  <- 0x000A0000 (640KB)
+|                  |
+|    Low Memory    |
+|                  |
++------------------+  <- 0x00000000
+

+ +

x86 Instruction Set

+ +

Two-operand instruction set +

Intel syntax: op dst, src +
AT&T (gcc/gas) syntax: op src, dst +
- uses b, w, l suffix on instructions to specify size of operands +
+
Operands are registers, constant, memory via register, memory via constant +

Examples: + +

AT&T syntax	"C"-ish equivalent +
movl %eax, %edx	edx = eax;	register mode +
movl $0x123, %edx	edx = 0x123;	immediate +
movl 0x123, %edx	edx = (int32_t)0x123;	direct +
movl (%ebx), %edx	edx = (int32_t)ebx;	indirect +
movl 4(%ebx), %edx	edx = (int32_t)(ebx+4);	displaced +

+ +

Instruction classes +
- data movement: MOV, PUSH, POP, ... +
- arithmetic: TEST, SHL, ADD, AND, ... +
- i/o: IN, OUT, ... +
- control: JMP, JZ, JNZ, CALL, RET +
- string: REP MOVSB, ... +
- system: IRET, INT +
+ +
Intel architecture manual Volume 2 is the reference + +

+ +

gcc x86 calling conventions

+ +

x86 dictates that stack grows down: + +

Example instruction	What it does +
pushl %eax +	+ subl $4, %esp + movl %eax, (%esp) +
popl %eax +	+ movl (%esp), %eax + addl $4, %esp +
call $0x12345 +	+ pushl %eip ^() + movl $0x12345, %eip ^() +
ret +	+ popl %eip ^(*) +

+ (*) Not real instructions + +

GCC dictates how the stack is used. + Contract between caller and callee on x86: +
- after call instruction: +
  - %eip points at first instruction of function +
  - %esp+4 points at first argument +
  - %esp points at return address +
  +
- after ret instruction: +
  - %eip contains return address +
  - %esp points at arguments pushed by caller +
  - called function may have trashed arguments +
  - %eax contains return value + (or trash if function is void) +
  - %ecx, %edx may be trashed +
  - %ebp, %ebx, %esi, %edi must contain contents from time of call +
  +
- Terminology: +
  - %eax, %ecx, %edx are "caller save" registers +
  - %ebp, %ebx, %esi, %edi are "callee save" registers +
  +
+ +

Functions can do anything that doesn't violate contract. + By convention, GCC does more: +

each function has a stack frame marked by %ebp, %esp +

+		       +------------+   |
+		       | arg 2      |   \
+		       +------------+    >- previous function's stack frame
+		       | arg 1      |   /
+		       +------------+   |
+		       | ret %eip   |   /
+		       +============+   
+		       | saved %ebp |   \
+		%ebp-> +------------+   |
+		       |            |   |
+		       |   local    |   \
+		       | variables, |    >- current function's stack frame
+		       |    etc.    |   /
+		       |            |   |
+		       |            |   |
+		%esp-> +------------+   /
+

%esp can move to make stack frame bigger, smaller +
%ebp points at saved %ebp from previous function, + chain to walk stack +
function prologue: +
```
+			pushl %ebp
+			movl %esp, %ebp
+		
```
+

function epilogue: +

+			movl %ebp, %esp
+			popl %ebp
+

+ or +

+			leave
+

+ +

Big example: +

C code +

+		int main(void) { return f(8)+1; }
+		int f(int x) { return g(x); }
+		int g(int x) { return x+3; }
+

assembler +

+		_main:
+					prologue
+			pushl %ebp
+			movl %esp, %ebp
+					body
+			pushl $8
+			call _f
+			addl $1, %eax
+					epilogue
+			movl %ebp, %esp
+			popl %ebp
+			ret
+		_f:
+					prologue
+			pushl %ebp
+			movl %esp, %ebp
+					body
+			pushl 8(%esp)
+			call _g
+					epilogue
+			movl %ebp, %esp
+			popl %ebp
+			ret
+
+		_g:
+					prologue
+			pushl %ebp
+			movl %esp, %ebp
+					save %ebx
+			pushl %ebx
+					body
+			movl 8(%ebp), %ebx
+			addl $3, %ebx
+			movl %ebx, %eax
+					restore %ebx
+			popl %ebx
+					epilogue
+			movl %ebp, %esp
+			popl %ebp
+			ret
+

+ +

Super-small _g: +

+		_g:
+			movl 4(%esp), %eax
+			addl $3, %eax
+			ret
+

+ +

Compiling, linking, loading: +
- Compiler takes C source code (ASCII text), + produces assembly language (also ASCII text) +
- Assembler takes assembly language (ASCII text), + produces .o file (binary, machine-readable!) +
- Linker takse multiple '.o's, + produces a single program image (binary) +
- Loader loads the program image into memory + at run-time and starts it executing +
+

+ + +

PC emulation

+ +

Emulator like Bochs works by +
- doing exactly what a real PC would do, +
- only implemented in software rather than hardware! +
+
Runs as a normal process in a "host" operating system (e.g., Linux) +
Uses normal process storage to hold emulated hardware state: + e.g., +
- Hold emulated CPU registers in global variables +
```
+		int32_t regs[8];
+		#define REG_EAX 1;
+		#define REG_EBX 2;
+		#define REG_ECX 3;
+		...
+		int32_t eip;
+		int16_t segregs[4];
+		...
+		
```
  +
- malloc a big chunk of (virtual) process memory + to hold emulated PC's (physical) memory +
+

Execute instructions by simulating them in a loop: +

+	for (;;) {
+		read_instruction();
+		switch (decode_instruction_opcode()) {
+		case OPCODE_ADD:
+			int src = decode_src_reg();
+			int dst = decode_dst_reg();
+			regs[dst] = regs[dst] + regs[src];
+			break;
+		case OPCODE_SUB:
+			int src = decode_src_reg();
+			int dst = decode_dst_reg();
+			regs[dst] = regs[dst] - regs[src];
+			break;
+		...
+		}
+		eip += instruction_length;
+	}
+

+ +

Simulate PC's physical memory map + by decoding emulated "physical" addresses just like a PC would: +

+	#define KB		1024
+	#define MB		1024*1024
+
+	#define LOW_MEMORY	640*KB
+	#define EXT_MEMORY	10*MB
+
+	uint8_t low_mem[LOW_MEMORY];
+	uint8_t ext_mem[EXT_MEMORY];
+	uint8_t bios_rom[64*KB];
+
+	uint8_t read_byte(uint32_t phys_addr) {
+		if (phys_addr < LOW_MEMORY)
+			return low_mem[phys_addr];
+		else if (phys_addr >= 960*KB && phys_addr < 1*MB)
+			return rom_bios[phys_addr - 960*KB];
+		else if (phys_addr >= 1*MB && phys_addr < 1*MB+EXT_MEMORY) {
+			return ext_mem[phys_addr-1*MB];
+		else ...
+	}
+
+	void write_byte(uint32_t phys_addr, uint8_t val) {
+		if (phys_addr < LOW_MEMORY)
+			low_mem[phys_addr] = val;
+		else if (phys_addr >= 960*KB && phys_addr < 1*MB)
+			; /* ignore attempted write to ROM! */
+		else if (phys_addr >= 1*MB && phys_addr < 1*MB+EXT_MEMORY) {
+			ext_mem[phys_addr-1*MB] = val;
+		else ...
+	}
+

Simulate I/O devices, etc., by detecting accesses to + "special" memory and I/O space and emulating the correct behavior: + e.g., +
- Reads/writes to emulated hard disk + transformed into reads/writes of a file on the host system +
- Writes to emulated VGA display hardware + transformed into drawing into an X window +
- Reads from emulated PC keyboard + transformed into reads from X input event queue +
+

-- cgit v1.2.3