Software Systems Spring 2008 For today, you should have: 1) worked on Homework 1 2) read the handout from LBoS and written a solution to the last puzzle 3) got your Linux partition squared away 4) read pages 11-16 of the cow book; compiled and run hello.c 5) brought a hand-held calculator (if you want) Today: 0) Homework 1 1) system model 2) Patterson's article 3) LBoS 4) reading lessons 5) C debugging For next time: 1) read Chapter 3 of the Cow Book quickly (don't worry about the details of commenting style) 2) read Chapter 4 of the Cow Book less quickly, and do Exercise 4-5. 3) read Tanenbaum and answer the questions below 4) finish Homework 1 and prepare for a quiz 5) read the next section from the LBoS and solve the puzzle Homework 1 ---------- What have we learned so far? Questions? Patterson's article ------------------- Comments? Questions? I started the semester with this article 1) because it says interesting things about latency and bandwidth 2) because it introduces several of the themes we will be talking about all semester. Not all of it will make sense at this point. 1) bandwidth improves faster than latency 2) Moore's law fast transistors and more pins, good for bandwidth fast transistors, good for latency bigger chips, bad for latency 3) physical lower bounds speed of light in networks capacitance on and between chips 4) marketing 5) improving latency usually improves bandwidth (Patterson may be a overstating his case here. There are also many ways to improve latency that consume bandwidth -- he mentions them later.) 6) sometimes improving bandwidth hurts latency 7) layered design hurts latency (operating system overhead) Tools for improving latency: 1) caching 2) replication 3) prediction Lessons for innovators: 1) if you have an idea that needs a little more bandwidth, you won't have long to wait. 2) if you need lower latency, the wait may be longer, or forever. 3) if trends continue, desperate latency-reducing strategies may pay off. Reading questions ----------------- Tanenbaum Chapter 1, pages 1-34. 1) skim the assigned pages for 2 minutes 2) read the questions below 3) read the assigned pages quickly (10-15 minutes) (skip the sections indicated below) 4) answer the questions below, re-reading when necessary Note: this section previews some topics we will cover later, and "reviews" some topics usually covered in CompArch, so there will probably be things you don't get. Don't spend more than 1 hour total on this reading. 1) In Figure 1-1. what do the horizontal lines between layers represent? 2) Why does some code run in kernel mode? 3) What does Tanenbaum mean by "virtual machine" and why is it useful? 4) What "resources" does an operating system manage? Why do they need management? Skip sections 1.2.1 and 1.2.2 and 1.2.3. Just skim section 1.2.4 and 1.2.5. History is boring. Skim Section 1.3. Figure 1-5 is at a pretty high level of abstraction. See my diagram attached to these notes for a more detailed version. 5) What does the program counter contain? 6) What does the stack pointer point to? Don't say "the stack". 7) What is a system call? Note: the word "memory" is sometimes used in the general sense to mean any kind of storage (including, for example, the disk), and sometimes to mean, specifically, the main memory (usually volatile DRAM or SRAM that is off-chip and connected to a dedicated memory bus). Note: the word "cache" is sometimes used in the general sense to mean any small, fast storage used to save temporary copies, and sometimes in the specific sense of the cache(s) that live between registers and main memory. 8) What is the difference between a track and a cylinder? Which do you think it more important from the point of view of performance? 9) On page 26, what is "relocation"? 10) What does the MMU do? 11) What is a controller? What is a device driver? 12) If you were designing an interface to a disk drive, would you use busy-waiting, or would you allow the disk drive to generate interrupts? 13) In Figure 1-11, what do the bridges do? Stop at the end of Section 1.4. Programming errors ------------------ C compilers are notorious for generating terrible error messages, and the run time system is even worse. So I think it is a good idea to make lots of errors on purpose to see what you get. mkdir ss cd ss mkdir code cd code wget http://wb/ss/code/bad1.c gcc -Wall -o bad1 bad1.c; ./bad1 Now try some of these errors: 1) change the spelling of include 2) change the spelling of stdio 3) leave out the .h on stdio.h 4) leave out the whole #include line 5) change the return type of main to void 6) leave out the return statement at the end 7) change the spelling of main 8) remove the * in char *name 9) change the spelling of name in the declaration 10) change the spelling of name where it is used 11) move the declaration of x after the first print statement 12) change the spelling of printf 13) leave out one of the semicolons 14) delete a parenthesis; add an extra parenthesis 15) delete or add a quotation mark 16) replace a double-quote with a single-quote 17) leave out the \n at the end of the format string 18) print the value of x/3 19) print the value of x/0 20) replace %d with %s in the second format string