Berkeley CS 61C Lecture 7

Here are some notes and corrections on this lecture:

At approximately 34 minutes in, the slides stop changing. Here's a workaround for that:
somebody posted a link to the slides in the comments.
This is it: http://inst.eecs.berkeley.edu/~cs61c/sp15/lec/07/2015Sp-CS61C-L07-kavs-M3-1up.pdf
You can run the lecture and the slides in two tabs in your browser. Keep the slides visible, and the audio from
the lecture will still play in the background. You'll have to scroll the slides yourself to keep up with the lecture.

Each note begins with a time; "ca." in front of a time means that it is approximate.

ca. 7:00 -- There is a chart showing the general format for stackframes (you'll need to come back to this lecture
when we get to stackframes). Notice that saved argument registers are higher up in memory (lower on the stack) than
the saved return address. Then in the example program sumSquare, these positions are reversed. Remember that this
format is a convention. The hardware does not care. Doing it this way will work, but I would have
preferred that the convention be observed. Conventions are useful; you know where to look for things.

ca. 10:00 -- The colors of the program text reflect the purpose of each bit of code: green is BOFB, red is EOFB,
and black is FAB.

ca. 10:00 -- In the same slide, the line of code "add $a1 $a0 $zero" is what we'd write as "move $a1 $a0",
i.e. a copy operation. He will introduce fakes (which they call pseudo-instructions) later in this lecture.
At this point, he's implementing the call mult(x, x) in assembly code from within sumSquare(x, y),
which means that x is in $a0. For the call mult(x, x) we need the x value in $a0 and in $a1; thus the copy.
This is why $a1 had to be saved on the stack; otherwise, the value of y would have been lost.

ca. 17:00 -- Here he is discussing labels. He makes the point that, when you write a label into a program, it is not
translated into the binary version of the program. It goes into a table that the assembler will use to look up
addresses. Only the linker will know where the labeled instruction ends up in the executable version of the program.
What this does for you is that you don't have to try to figure out where things will be in the executable. The
assembler and linker will find the correct address and use it. This saves you a lot of trouble.
When you change code in the program text, the positions of things can change. When you reassemble and relink,
the assembler and linker will figure out the new locations and use them.

ca. 19:00 -- Never mind $gp. We won't use it.

ca. 20:20 -- C programs can have global variables. These variables can be used at any time by any code
in the program. They reside in the static data segment. "Static" means that they don't move around once they are
placed there. Immediately above the static memory is the dynamic memory. This is where the program can allocate
and deallocate memory after it has started running. If your program creates an object, it will be placed in
dynamic memory. C does not have garbage collection as Java does. It's up to you to free up the memory of objects
that will not be reused.

ca. 21:45 -- The upper half of the address space (0x80000000 and above) is reserved for the operating system.
User programs have no access to it. You see this in memory diagrams that have 0x7FFFFFFC at the top.

ca. 39:00 -- I don't like "register target" as a name for rt. Just think of "t" as the next letter after "s".
The 2nd edition of the book used rd instead of rt for the destination register in I-format instructions.
I like that better even though it involves having rd in different places in R-format and I-format instructions.

ca. 42 -- A couple of slides refer to "COD". This is the textbook: Computer Organization and Design.