See Syllabus for topics
Using MIPS CPU, to go with text, and it’s the simplest one.
First study MIPS assembly language, to get close to the CPU. We’re particularly interested in how C turns into machine instructions.
We’ll use SPIM simulator for running MIPS assembler—see link for download on the class web page, www.cs.umb.edu/cs641. More next time.
For C, we’ll use a cross compiler, mips-gcc: runs on our Linux system, sf06.cs.umb.edu, outputs MIPS assembly language we can read.
CPUs: 32 bits vs. 64 bits.: The number of bits is indicating the size of the memory address.
With 32 bits, there can be 2^32 = 4G different addresses. All current processors use an address on each byte (“byte-addressed”), so this means 4GB of addressable memory. Starting in the 90s, this was limiting big servers, so the push for 64-bit CPUs began.
CPUs of interest to
us:
MIPS—described in text, used in cell phones, etc. Designed originally by Hennessey, one of the authors of the book, in mid 80s, 64 bit version released in ’91.
x86—Intel’s 32 bit CPUs: 8086, 386, 486, various Pentiums. Also sold by AMD. Probably describes the CPU in your PC, unless it’s 64-bit.
x86_64—AMD’s extension of x86 to 64 bits (’01), eventually adopted by Intel as well. CPU for sf06.cs.umb.edu, our Linux machine.
Sparc—by Sun, released in 32 bits in ’87, 64 bits in ’93. CPU for users.cs.umb.edu, blade*.cs.umb.edu, etc. Inspired by Peterson’s RISC work at Berkeley (the other author).
MIPS and Sparc are both RISC processors. See chart on pg E-44 for more RISC CPU genealogy if interested. x86 and x86_64 are CISC processors (complex instruction set).
Idea of RISC: implement only a small set of core instructions, freeing up transistors in the CPU for more registers, cache, etc. Get more code to execute inside the CPU, to avoid references to memory, that take time (idea of memory barrier), because main memory is made out of little capacitors, not digital circuitry.
Pg. 8: goals
pg. 10 layers and the OS. This layers picture may be misleading. The OS is there but does not interfere with instruction-by-instruction execution of your program. Your program is talking directly to the real CPU. (This is not actually true with the simulator case, but is with the normal execution case.)
The OS only comes into play at special moments. One is when your time sharing quantum is over, when the OS takes the CPU away from your program, to be returned a few moments later. But it is done so cleverly that you never notice it happening.
Another is when you type a character of input, and the OS wakes up on an interrupt, and handles it.
Because of the fact that the OS is not involved in simple execution, it won’t figure prominently in this course. It goes the other way: you need to know this material to fully understand OS behavior.