Labs

These are Dave Patterson's comments about CS61C, "Machine Structures," taught at U.C. Berkeley in Spring 1999. Some notes are from before I started lecturing, but most are as a result of the lectures. I suggest reading them if you are going to teach the material and try to use the lecture slides.

CS61C is a large class, almost all freshmen and sophomores, that requires a cadre of Teaching Assistants and Readers to manage the class. The assignments are broken into things completed in scheduled computer labs, homework exercises, and larger projects, plus midterm and final. They have taken one intro course based on Abelson and Sussman in Scheme (CS61A), and may or may not have taken a data structures course in Java (CS61B). They are required to know how to write a recursive program in C, C++, or Java. They are expected to learn some C as part of 61C.

Prior versions had 2 midterms and 1 final, but to reduce the workload on the teaching staff to makeup and grade the exams, I limited it to 1 midterm. This gave enough time for TA's to help make up the questions, which is good for them. We started about 3 weeks before the exam, and I think this gave us time to get a fairly-well debugged midterm and final. The questions that we didn't use we placed on the practice midterm and final.

As the goal is education, its great to find effective ways for students to study on their own to prepare for the exam. Old tests, practice exams, and review sessions all help them learn the material.

I was satisfied that 1 midterm + 1 final, given all the support infrastructure for each exam, was sufficient for grading and made the class better for everyone

Labs

Roughly 1/week
Due in following week, checked by TA
It worked well to give WWW survey assignments in first lab, lab before midterm, and last lab
Need to get TA's to agree on a grading scheme in the lab for consistent and fair grading
Since we had only 50 minutes scheduled for the lab, it remains problematic what to do with the labs. In talking with TA's afterwards, once generic suggestion is to have creation of test rig to exercise the project. Labs Tue/Wed and Lab Due Wed/Thu
Also, for cache.c lab (as simplified for class) which is lab 9, ask why part of a line could be sloped vs. level (answer: some strides mostly hits, not hits and other strides mostly misses, but not all misses)
End of class survey on which labs was favorite, least favorite

List of 11 labs	Favorite	Least Favorite
1. First MIPS program	35	20
2. Second, Third MIPS functions: translate multiplier routines	9	12
3. Fourth MIPS program: sum of array function	26	58
4. Debugging: find at least 2 errors in MIPS program	8	16
5. First part of Project 3, instruction interpretation	16	4
6. Polling I/O lab	15	4
7. (midterm survey; choice not available)
8. Network Examples: ping, traceroute	66	24
9. Program to find cache parameters	32	15
10. Processes, virtual memory, physical memory, swap space	8	49
11. MIPS vs. HP vs. Intel instruction sets: CPI, optimized vs. unopt code	24	31

Looks like problems with Labs 3, 10; Labs 1, 8, 9 seemed popular.

Read written comments on likes, dislikes of labs to get betters insights on revision.

Projects

Done in addition to other items
Due Wednesdays
Graded by computer if programs
Next Time, revise solution to instruction simulator lab so it takes all instructions through 4 or 5 steps, as in lectures 20, 21 (fetch instruction, inc PC; read 2 reg operands; then divide into instruction classes; steps 4 & 5 for load); modularize simulator so that each step is a function, and they fill in the code of the functions
End of class survey on which project was favorite, least favorite

List of 6 projects (plus goals)	Favorite	Least Favorite
1. Philspel (learn C)	32	101
2. Disassembler (learn MIPS format and practice C)	30	29
3. Instruction Interpreter (understand interpretation, learn MIPS, and practice C)	53	10
4. Interrupt Handler in MIPS (understand interrupts vs. polling, practice MIPS)	46	34
5. Cache Simulator (understand caches, and practice C)	57	52
6. Sprintf in MIPS (Review of parameter passing, understand how C is implemented, practice MIPS)	39	26

I'm sure Lab 1 complaints are in part because just threw them into C without a lecture on C; Also things to warn them about C vs. Java specifically for this lab
Read written comments to learn how to improve projects

Assignments

Roughly 1/week
Due Wednesdays at 7PM (avoids Mondays, avoids class or lab sections)
Graded by readers
As polled in class, separate HW deadline from project deadline date to 2 days later only in the weeks a project is due
Suggestion for next semester; Wed 7PM goal with 8AM Thursday deadline didn't work; suggestion to say deadline is Wed 7PM, turning it in "too often" Thursday 8AM may affect your grade

One issue is keeping on top of the readers to get things back in a timely fashion, especially

Initial Lab/Project Ideas

Followed Nick Weavers’s lead and give them a C programming assignment presuming that can learn on own
Notes: Java derived from C++ which is derived from C; should be able to pick this up on your own
Be sure to add that before submit, get it to run on both HP running HPUX and x86 running Solaris to help catch bugs; some compilers more forgiving than others
Perhaps ask which is stricter? Why?

I am creating about 60 slides a week for the class, which is consuming

an AMAZING amount of time, but I'm sure I will get my reward for reuse in later course offerings (and probably helping other instructors in cyberspace as well), so I don't mind as much.

Grand total was 926 slides, or more pages than in COD

My class has 370 students (!) in the 5th week of classes, so part of challenge is administrative as well.

One idea to work on next time is to figure out how to get the people in the back of the class to stop whispering to each other; they seem to think they're not bothering anyone back there, Also need to turn up the microphone, or perhaps reducing the talking will make it possible to hear better. I would now take charge in the first class, turning off lights to get their attention, and then insist on quiet or ask them to leave. Perhaps wonder around with the wireless mike? If TA's sit in the back, perhaps they can make suggestions how well people are paying attention
I asked Tas, and they had no idea. They thought lights off was a bit rude.

Notes from teaching class.

I listed the Big Ideas of the course in the first lecture, and then am highlighting them when they appear in the lectures, and making sure the exams test them. This top-down approach to education makes a lot of sense, and is fairly satisfying. It gives the course a philosophy to follow when issues arise. We are teaching Big Ideas, picking up assembly language as a consequence of learning those ideas. End of class survey:

Big Ideas	lost!	significant questions		understand well		know very well
Principle of abstraction	3	20	117		143
Pliable Data	13	27	87		157
Stored program concept	1	26	89		167
Principle of Locality	11	76	128		68
Exploiting parallelism	11	83	128		62
Performance measurement	14	100	125		43

Seems like it wored well; only 1 with many questions was performance measurement, and we only spent 1 lecture on the topic

I needed to work with the slide format to make sure 100s of students can read them in a giant room. I think its settled by the 3rd lecture, and the 1st lecture was hard to read for them. I also had to find fonts that worked both on my Mac and in the True Type font of my Sony PC portable. When I do it again, I would go through the 1st and 2^nd lecture to make every font and size match the remaining lectures.

I did a Web-based survey to find out what they already know, how much computing and printing they have access too, when I need to have the slides ready if they want to print them before lecture, .... I'll do this again at the midterm and final, with different questions. It worked great, and you get instant analysis.

My conclusion was that as long as the slides were posted by midnight the night before the lecture, most student could print copies of the slides themselves (if they wanted them) either on their own printer or on the dorm's printer

Although I relied on most of them to print the slides themselves, I found it was helpful to ask my secretary to make copies for 20% of the class on the morning of the lecture and place them in the lab for those who didn't have easy access to a printer

Another thing I tried towards the end of the class was to have review lectures on difficult topics vs. tell them about the latest neat things in CS&E; while some would certainly have enjoyed hearing about them, I think the vast majority benefited from hearing the hard stuff one more time. I did reviews of parameter passing on stacks, cache/VM/TLB, and interrupts/polling. Also, one benefit was that since you have covered everything once in prior lectures, you could give fuller explanations in the review lectures. For example, second time through could talk about page faults when talking about interrupts. Students clearly learned a lot in the class, so it seems like it worked. Here is what the students thought:

Review lecture survey	waste of time	marginal	helpful	very helpful!
Review lectures in general	6	58	152	63
Stack passing review lecture	6	51	157	57
Cache/VM/TLB review lecture	3	59	162	47
Polling/interrupt review lecture	3	38	102	20
Midterm review	13	62	114	73

I went through the material quite differently from the book order, and was fairly happy about it, with a few small exceptions mentioned below.

Two things I'm trying as a theme in the lectures, which I give twice a week. The goal is to make them understand what they are learning can help with, and that its really important in the real world:

"What's This Stuff Good For" Finding novel applications of generally embedded computers, e.g., inexpensive proesthetic arms and hands.

"Computers In the News" Showing ideas they are learning help explain stuff they read about in the newspapers, e.g., flap over privacy and unique IDs for Intel processors. This is machine language stuff. I try to pick things that happened in the last week.

I do one on Wednesday and one on Friday. This also takes some time, but makes the lectures more fun to do

Student surveys suggested they like this a lot; "Wow, the stuff I am learning is actually useful and important"

There are assembly language programming bugs in some of the slides, so they need to be fixed

Lecture order: I did a little function call, then machine representative, then more function call details. I would have made machine representation first, then 2 lectures on function calls next time.

Not clear its best to skip machine representation to get to procedures, as its hard to understand addresses without machine representation

case/swtich via jump tables and jr was hard to understand;

next time just introduce jr as part of procedures, and make case/switch via jump tables an assignment that works faster?

Need to understand jump tables for Interrupt Routine, just do that after call, return

Floating point was harder for them to understand than I expected, so we'll go over it again more slowly; I did it as part of 1 lecture (characters, strings in the other half), so I slowed it down next lecture.

I did I/O before caches/VM just to give them more assembly programming labs, but you can make a case you doing caches/VM first. Since VM appears to be harder to understand than interrupts, perhaps its good to leave it in the order I presented the material

Although cache lectures went well, the 1/2 of Lecture 18 that introduced virtual memory didn't work well. No one followed it. It would have been better instead to have done a cache example with write through and write back, possibly with L2 cache if had time, to better teach the ideas. Will start over with Lecture 19 on VM

Per class request, added a lecture on Intel 80x86 on it instead of a review topic; included HP as well so could comparing instruction sets as part of last lab.

Regarding the lecture on multiply and divide: multiply went well, but not divide. Next time just concentrate on multiply, and say that divide is similar, but based on shifting and subtracting instead, but give no details

Regarding Review lecture on Caches/VM/TLB; (Lecture 26) 6 slide explanation of what happens in a simplified 21064 lost them. Try one of two things; 2 screens so that can follow path on the screen while reading the text, or make a simplified drawing of the 21064 that's fills 1/2 the slide, and then just go through more slides; might do both because the simplified version would easier to follow on a separate screen; probably have to add numbers for the steps too

Survey results from midterm: things hard for them to follow were interrupts, polling, and procedures; they got all the big ideas (except principle of locality, which was new, so too not surprising)

Survey results from end of class; things still a little confused on are paging, TLB, branch prediction, delayed branch, load-use hazards. Here are the survey results

Little Topics	lost!	significant questions	understand well	know very well
C/Asm Operations, operands	2	11	101	162
C/Asm Decisions	2	22	110	148
C/Asm constants	2	22	107	152
C/Asm Procedures, register conventions	2	19	126	136
C/Asm Procedures, stack v. heap v. static	8	71	148	56
Addressing modes	2	54	156	68
C/Asm pointers	7	51	137	88
C/Asm Characters, Strings	2	38	141	101
2's complement	1	16	113	153
Logical operations: shift, and, or	1	11	107	164
Floating point	9	51	159	63
Polling I/O	9	74	136	64
Interrupt I/O	9	86	144	44
Storage Devices	6	59	162	56
LRU	17	53	120	91
Direct Mapped/Set Associative/Fully Associative	10	50	142	81
TLB	38	123	85	35
Paging	34	120	106	23
Datapath block diagram	21	108	120	33
ALU	18	83	132	48
Multiply	18	79	142	44
Divide	21	91	136	35
Latency vs. Throughput	8	97	129	49
CPI	10	67	141	65
Pipelined Instruction Execution	9	76	137	61
Structural Hazards	11	95	142	35
Control Hazards	11	93	144	36
Data Hazards	10	93	143	38
Branch Prediction	12	108	123	39
Delayed Branch	13	110	117	43
Forwarding	16	87	135	45
Load-use Hazard	37	133	88	24