CS 3410 - Spring 2012

Computer System Organization and Programming

Instructor: Hakim Weatherspoon

Cornell University Computer Science Department, Spring 2012

How to Lose in CS 0xd52

Proven ways to make your lab and group projects harder:

  1. Don't start until three days before the assignment is due. Then pull three all-nighters in a row. Unfortunately, this approach will work fine for lab0, designed to get everyone warmed up and on the same page. While all-night hacking sessions can be fun, too much caffeine can and will make you hallucinate. For instance, if you are convinced that the course staff will grant you an extension for having started late, you are hallucinating.

  2. Designate your project partner as the master hacker and have her do all the work. That way she will burn out 3/4 of the way through the course and you will not be able to finish the project since only she understands it.

  3. Decide that your project partner is useless and don't invite him to group meetings. This makes you the lone master hacker. Two people can play this game, but the chances are pretty good that both will simultaneously burn out 3/4ths of the way through the projects.

  4. Have a different person implement each project, in a grown-up's version of the hot-potato game. Unfortunately, this will work fairly well early on, but by the fifth or sixth assignment the person writing the code will have no idea what is going on. Chances are pretty good (well, 50/50) that the person having to deal with the problem, and the associated nervous breakdown, will be your partner!

  5. Have everyone implement separate pieces of the system with no discussion of how they will fit together. Ideally, talk to your project partner just once to do the split, then do not talk at all until 15 minutes before the deadline. Bet this is how real-world engineering is done, right?

  6. Opposite of the previous technique: Work extremely closely all the time, spending all your time talking among yourselves rather than doing actual implementation. The group will slow down to at most the speed of one person. For extra effectiveness, everyone simultaneously edits different files in the same directory. That way, the whole system never works at any given time because something is always broken; also, you can't figure out which of entirely different, untested modifications are causing the current bug.

  7. Don't ask the TAs or the professor any questions when design problems come up; just put off working on the project and hope the problems will magically solve themselves before the due date.

  8. Do NOT look anything up in the MIPS reference manual. If it's important, then course staff can individually tutor you. If not, it's not worth implementing!

  9. Don't use any of the techniques for processor implementation or systems programming that you learn in this class. This works best if you don't attend class at all, so you avoid polluting your mind with the course material. Develop your own instruction set instead of using the common MIPS interface, use a different tool set from everyone else where you have to reimplement all of the modules we provide to you, modify the simulator so it implements new semantics. Do not use Makefiles, write your own scripts for compiling the projects. Your system won't provide all the required functionality, will not support any of the test cases and applications we give out, and as a bonus, will crash or hang routinely.

  10. Don't bother doing any of the homework assignments; surely, they are each too small a component of your grade to worry about, right ? The sections are for the weaklings who need to be told what to do; certainly you could do better. When you ultimately fail to make the deadline, try to look really innocent as you plead for the extravagant mercy of the course staff.

  11. If you fall behind on a project, do not work overtime to catch up. Instead, work on the previous project when all your peers are working on the current one. You can even sound them out for ideas and figure out how they implemented the previous project, which will ensure that your implementation will be better than theirs. If your peers spend M weeks on N projects, and you spend M weeks on N-1, surely you'll roll all over them on those N-1 projects. Now, if only you could get the course staff to grade your previous project instead of the current one, everything would be perfect!

  12. When your projects get boring, spice your life up by swapping project partners. Ideally, you will do this two thirds of the way into the course so that your ex-partners will be completely lost when you tell them that you want out and that they will need to work with someone else. Or, on the flipside, incite your partner to leave by not doing your part of the project. Try to clarify the situation through extended conversations with course staff about who wrote which exact line of code in each project. Better yet, try to convince the course staff that they should up your grade while cranking down your partners'. It's a zero sum game, but that doesn't mean that you couldn't come out ahead.

  13. Add a fifth wheel to your project. The course projects are carefully designed to cover the most important aspects of a given topic and produce easily testable systems. As a result, they leave out some non-fundamental details. Get all worked up about the lack of "realism," and jam as many unnecessary optimizations into your project as you can. The more premature and unjustified, the better - surely you are not going to waste time quantitatively justifying the optimizations, when you could be going ahead and implementing them! Of course, this will make your base functionality unstable and prone to crash, but if you pull this strategy off really well, your project will be completely untestable anyway because it implements a different set of semantics than everyone else's. Don't forget to argue with the course staff that, while your processor cannot reliably execute one instruction, you should get extra credit for having implemented a super-pipelined, super-scalar design with out-of-order issue and speculative execution.

  14. Our all time favorite: first, write ALL your code on paper. Then enter it into the computer. Look puzzled as the compiler discovers 358 errors and 597 warnings. What could be going wrong here? Surely, this system implementation technique worked in CS 1110 -- why would it not work in a 3000-level course? Probably because the compiler does not correctly implement the C standard. Demand that the course staff fix up the compiler at once so your obviously correct code can be parsed. Ask for extensive help getting rid of the compiler errors (never mind the warnings - they too are for weaklings to fret over). Look even more puzzled as your system compiles but core dumps/hangs/behaves erratically upon execution. It's either because the compiler is producing bad assembly code underneath the covers, or the C runtime has a bug, but which is it???

Based on How to lose in CS 412 by Andrew Myers and How to lose in CS 316 by Emin Gün Sirer.