Introduction to Computer Systems

1. Introduction to Computer Systems 15-213 “The Class That Gives CMU Its Zip!” • Topics: • Introduction • Theme • Five great realities of computer systems • How this fits within CS curriculum And gives Doha ?? John Barr January 15, 2007 class01a.ppt 15-213 F ’06

2. Teaching staff • Instructor • John Barr • Majd Sakr Come talk to me anytime! (Or phone or send email)

3. Textbooks • Randal E. Bryant and David R. O’Hallaron, • “Computer Systems: A Programmer’s Perspective”, Prentice Hall 2003. • csapp.cs.cmu.edu • Brian Kernighan and Dennis Ritchie, • “The C Programming Language, Second Edition”, Prentice Hall, 1988 • Neil Matthew and Richard Stones, • “Beginning Linux Programming, Third Edition”, Wrox Press, 2004 • Marc J. Rochkind • “Advanced UNIX Programming, 2nd ed.”, Addison-Wesley, 2004

4. Course Components • Lectures • Higher level concepts • Recitations • Applied concepts, important tools and skills for labs, clarification of lectures, exam coverage • Labs • The heart of the course • 1 or 2 weeks • Provide in-depth understanding of an aspect of systems • Programming and measurement

5. Getting Help • Web • http://www.qatar.cmu.edu/cs/15213/CS395.html • Copies of lectures, assignments, exams, solutions • Clarifications to assignments • Personal help • Professor: • John Barr office hour, e-mail, call (8295) or just knock at door

6. Policies: Assignments • Work groups • You must work alone on all labs • Handins • Assignments due at 11:59pm on specified due date. • Typically 11:59pm Wednesday evening • Electronic handins only (no exceptions!). • Makeup exams and assignments • OK, but must make PRIOR arrangements with either Prof. Barr • Appealing grades • Within 7 days of due date or exam date. • Talk to Prof. Barr.

7. Cheating • What is cheating? • Sharing code: either by copying, retyping, looking at, or supplying a copy of a file. • Coaching: helping your friend to write a lab, line by line. • What is NOT cheating? • Helping others use systems or tools. • Helping others with high-level design issues. • Helping others debug their code. • Penalty for cheating: • Removal from course with failing grade. • Detection of cheating: • We do check and our tools for doing this are much better than you think!

8. Policies: Grading • Exams (40%) • Two in class exams (10% each) • Final (20%) • All exams are open book / open notes. • Labs (50%) • 5-7 labs (8-12% each • Quizzes (10%) • 7-10 labs (8-12% each)

9. Facilities • Assignments will use the Intel Computer Systems Cluster • 2 Intel machines • Rack mounted in IT server room. • Your accounts are ready. • Getting help with the cluster machines: • See course Web page for info

10. Account Initialization • For using the Linux machines: • Read description on the course web-page carefully • Run checkin script to set-up Kerberos credentials • Keep your code in a directory (such as “213hw”) on your Andrew account • Usessh linux-cs.qatar.cmu.edu • Use the afs drop box: • Login to your linux box • Tar your finished lab and name the file lastname.tar • Copy (cp) your finished lab to the appropriate lab directory. For lab 1 copy it to: • /afs/qatar.cmu.edu/course/15/213/lab1 • For lab 2 copy it to: • /afs/qatar.cmu.edu/course/15/213/lab2 • Etc.

11. Course Theme • Abstraction is good, but don’t forget reality! • Courses to date emphasize abstraction • Abstract data types • Asymptotic analysis • These abstractions have limits • Especially in the presence of bugs • Need to understand underlying implementations

12. Course Theme • Useful outcomes • Become more effective programmers • Able to find and eliminate bugs efficiently • Able to tune program performance • Prepare for later “systems” classes in CS & ECE • Compilers, Operating Systems, Networks, Computer Architecture, Embedded Systems

13. Great Reality #1 • Information is Bits + Context • Examples • Source Program: • #include <stdio.h> • int main() • { • printf(“hello world\n”); • } • ASCII representation of the source program (text file): # i n c l u d e <sp> • 105 110 99 108 117 100 101 32 < s t d i o . h > • 115 116 100 105 111 46 104 62 Etc…. • Actual representation on the disk: 00100011 01101001 01100011 01101100 01110101 01100100 …

14. All information is represented as bits • Including disk files, programs in memory, user data in memory, data transferred across the internet, … • The only thing that distinguishes data objects is context • Same bits may represent an integer, floating-point number, character string, or machine instruction.

15. Great Reality #1 cont. • Int’s are not Integers, Float’s are not Reals • Examples • Is x2 ≥ 0? • Float’s: Yes! • Int’s: • 40000 * 40000 --> 1600000000 • 50000 * 50000 --> ?? • Is (x + y) + z = x + (y + z)? • Unsigned & Signed Int’s: Yes! • Float’s: • (1e20 + -1e20) + 3.14 --> 3.14 • 1e20 + (-1e20 + 3.14) --> ?? -1794967296 0

16. Computer Arithmetic • Does not generate random values • Arithmetic operations have important mathematical properties • Cannot assume “usual” properties • Due to finiteness of representations • Integer operations satisfy “ring” properties • Commutativity, associativity, distributivity • Floating point operations satisfy “ordering” properties • Monotonicity, values of signs

17. Computer Arithmetic • Observation • Need to understand which abstractions apply in which contexts • Important issues for compiler writers and serious application programmers

18. Great Reality #2 • You’ve got to know assembly • Chances are, you’ll never write program in assembly • Compilers are much better & more patient than you are • Understanding assembly key to machine-level execution model • Behavior of programs in presence of bugs • High-level language model breaks down • Link-time errors hard to find • Tuning program performance • Understanding sources of program inefficiency • Avoiding security holes • Example: buffer overflow bugs • Implementing system software • Compiler has machine code as target • Operating systems must manage process state

19. Compilers • Programs are translated by other programs into different forms • A C program in text-file format must be translated in a low-level binary format • Humans can read the text-file • Computers can read the binary • Assembly is (basically) a human readable form of binary • Translate source to binary in Unix by compiler driver: unix> gcc –o hello hello.c

20. Compilers • Translation phases: • Preprocessing phase. The preprocessor (cpp) modifies the original C program according to directives that begin with #hello.chello.i • Compilation phase. The compiler (ccl) translates the text file into a different text file containing an assembly level file.hello.i hello.s • Assembly phase. The assembler (as) translates the assembly file into a machine language (binary) format. hello.s  hello.o • Linking phase. The linker (ld) merges separately compiled files, libraries (like stdio), etc. into an executable object file that can be loaded into memory and run. hello.0 printf.o  hello

21. Compilers • Translation phases: • figure 1.3 printf.o Pre- processor (cpp) Compiler (cc1) Assembler (as) Linker (ld) hello.c hello.i hello.s hello.o hello Source program (text) Assembly program (text) Modified source program (text) Relocatable object programs (binary) Executable object program (binary)

22. Executing programs • Processors only understand binary programs • The hello.c program has been translated to the executable object file hello and stored on disk • To run, we type the program’s name: unix> ./hello hello world unix> • A shell loads and runs the program.

23. Executing programs • Organization • To understand how the program is run, must understand how the hardware is organized. • figure 1.4

24. Executing programs • The central processing unit (CPU). The engine that interprets (or executes) instructions stored in main memory. • Consists of many electronic devices and small pieces of memory (registers): • Control unit (CU) • Arithmetic/Logic Unit (ALU) • Program counter (PC) register that points at next instruction in main memory. • Other general and special purpose registers. CU

25. Executing programs • The central processing unit (CPU). Continued. • Performs the same basic tasks over and over again in a cycle (called the execution cycle) • Fetch the next instruction from main memory • Decode (or interpret) the bits in the instruction • Executes the instruction • Update the PC to point at the next instruction • There are only a few simple operations (or instructions) that a processor can execute

26. CPU Register file ALU PC System bus Memory bus Main memory "hello" Bus interface I/O bridge Expansion slots for other devices such as network adapters I/O bus USB controller Graphics adapter Disk controller Mouse Keyboard Display Disk User types "hello" Executing programs • Putting it all together: running the hello program • When we type “./hello” the shell program reads each character and stores each into memory.

27. CPU Register file ALU PC System bus Memory bus Main memory "hello,world\n" Bus interface I/O bridge hello code Expansion slots for other devices such as network adapters I/O bus USB controller Graphics adapter Disk controller Mouse Keyboard Display hello executable stored on disk Disk Executing programs • Putting it all together: running the hello program • When we hit the enter key, the shell loads the executable hello file by executing a sequence of instructions that copies the code and data from the disk to the memory. Uses DMA to bypass the CPU

28. Executing programs • Putting it all together: running the hello program • Now the CPU begins executing the instructions in the hello program. • The program instructions copy the bytes in the string “hello world\n” from memory to the register file, • then from there to the display device. • The device displays the string on the screen. • See next slide.

29. Running the hello program CPU Register file ALU PC System bus Memory bus Main memory "hello,world\n" Bus interface I/O bridge hello code I/O bus Expansion slots for other devices such as network adapters USB controller Graphics adapter Disk controller Mouse Keyboard Display Disk hello executable stored on disk "hello,world\n"

30. Role within Curriculum • Becoming a Computer Scientist • 211: How to design efficient programs • 212: How to use abstraction to create elegant and scalable solutions • 213: Understand what a computer is and how to use it effectively and practically CS 212 Execution Models CS 213 Systems CS 123 C Programming CS 211 Fundamental Structures

31. Role within Curriculum CS 441 Networks CS 412 Operating Systems CS 411 Compilers ECE 447 Architecture • Transition from Abstract to Concrete! • From: high-level language model • To: underlying implementation ECE 349 Embedded Systems Network Protocols Processes Mem. Mgmt Machine Code Optimization CS 395 Systems Exec. Model Memory System CS 212 Execution Models CS 213 Systems Data Structures Applications Programming CS 211 Fundamental Structures CS 113 C Programming

32. Course Perspective • Most Systems Courses are Builder-Centric • Computer Architecture • Design pipelined processor in Verilog • Operating Systems • Implement large portions of operating system • Compilers • Write compiler for simple language • Networking • Implement and simulate network protocols

33. Course Perspective (Cont.) • Our Course is Programmer-Centric • Purpose is to show how by knowing more about the underlying system, one can be more effective as a programmer • Enable you to • Write programs that are more reliable and efficient • Incorporate features that require hooks into OS • E.g., concurrency, signal handlers • Not just a course for dedicated hackers • We bring out the hidden hacker in everyone • Cover material in this course that you won’t see elsewhere

34. Memory Performance Example • Implementations of Matrix Multiplication • Multiple ways to nest loops /* ijk */ for (i=0; i<n; i++) { for (j=0; j<n; j++) { sum = 0.0; for (k=0; k<n; k++) sum += a[i][k] * b[k][j]; c[i][j] = sum; } } /* jik */ for (j=0; j<n; j++) { for (i=0; i<n; i++) { sum = 0.0; for (k=0; k<n; k++) sum += a[i][k] * b[k][j]; c[i][j] = sum } }

35. 160 140 120 ijk 100 ikj jik 80 60 40 20 0 matrix size (n) Matmult Performance (Alpha 21164) Too big for L1 Cache Too big for L2 Cache jki throughput kij kji

36. 160 140 120 100 bijk bikj 80 ijk ikj 60 40 20 0 50 75 100 125 150 175 200 225 250 275 300 325 350 375 400 425 450 475 500 matrix size (n) Blocked matmult perf (Alpha 21164)

37. Real Memory Performance Pointer-Chase Results 1000 100 Iteration Time [ns] 10 1 From Tom Womack’s memory latency benchmark

38. Great Reality #4 • There’s more to performance than asymptotic complexity • Constant factors matter too! • Easily see 10:1 performance range depending on how code written • Must optimize at multiple levels: algorithm, data representations, procedures, and loops

39. Great Reality #4 • There’s more to performance than asymptotic complexity • Must understand system to optimize performance • How programs compiled and executed • How to measure program performance and identify bottlenecks • How to improve performance without destroying code modularity and generality

40. Great Reality #5 • The operating system manages the hardware • No user program can access any hardware directly • Writing/Reading to/from disk, keyboard, display, RAM all controlled by the OS Application programs Software Operating system Processor Main memory I/O devices Hardware

41. OS • The operating system manages the hardware • Purpose of the OS • Protect the hardware from misuse (accidental and purposeful) • Provide simple and easy access to hardware • Ensure efficient use of hardware

42. OS • The operating system manages the hardware • Abstractions provided by the OS • Processes • Virtual memory • Files Processes Virtual memory Files Processor Main memory I/O devices

43. OS: Processes • Abstraction of a running program provided by the OS • Multiple processes can run concurrently • Each process appears to have exclusive use of the hardware • Reality: process instructions are interleaved • OS performs this interleaving with a mechanism called context switching. • The OS keeps track of all state information (or context) that a process needs to run. • Includes value of PC and register values

44. OS: Concurrency • Appearance of simultaneous execution • Multiple processes can run concurrently • Each process appears to have exclusive use of the hardware • Reality: process instructions are interleaved • OS performs this interleaving with a mechanism called context switching. • The OS keeps track of all state information (or context) that a process needs to run. • Includes value of PC and register values

45. OS: Concurrency • Example • Shell process and hello process execute concurrently • We consider concurrency in chapter 8 • Concurrency distorts the notion of time. Chapter 9 discusses various notions of time in a modern system. shell process hello process Time Application code Context switch OS code Application code Context switch OS code Application code

46. OS: Threads • A process can contain multiple execution units, called threads • Each thread runs in the process's context • Each thread shares code and global data. • Easier and more efficient to share information between threads than processes • Discuss in chapter 13

47. OS: Virtual Memory • An abstraction that provides each process with the illusion that it has exclusive use of main memory (RAM) • This illusion is called virtual memory • Each process is provided a virtual address space • Example: see next slide for Linux virtual address space • VM requires OS and hardware to interact • Use disk to extend RAM • Requires translation of every logical address to a physical address • Discuss in chapter 10

48. OS: Concurrency Memory invisible to user code 0xffffffff Kernel virtual memory 0xc0000000 User stack (created at runtime) Dynamic Space used for function calls Chap 3 Shared Libraries like stdio, math, etc. Chap 7 Memory mapped region for shared libraries printf() function 0x40000000 Heap: dynamically allocated (malloc/free) Chap 10 Run-time heap (created at runtime by malloc) Program code and global variables Chap 7 Read/write data Loaded from the hello executable file Read-only code and data 0x08048000 Unused 0

49. OS: Files • A sequence of bytes • Every I/O device is modeled as a file. • Includes disks, keyboards, displays, networks • All input/output performed by reading/writing files • Provides programs with a uniform view of all the varied I/O devices that might be part of a system • Discussed in chapter 11

50. Great Reality #6 • Computers do more than execute programs • They need to get data in and out • I/O system critical to program reliability and performance • Network is just another I/O device