Class Project 2

At this point in the class, you hopefully know enough assembly language to actually use it to solve problems, so I'd like you to use it to solve a problem you're interested in.

From the syllabus, each of the two course projects is 15% of your course grade, so it should have some pretty good stuff.  Conversely, the total end-to-end time for the project is only a few weeks, so keep it manageable!

Project Deliverables

   November 2017      
Su Mo Tu We Th Fr Sa  
19 20 21 22 23 24 25  <- Thanksgiving break
26 27 28 29 30        <- Rough draft due
                      
   December 2017      
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  <- Project presentations
10 11 12 13 14 15 16  <- Final draft due (on day of final exam)

On November 29, I'd like your rough draft code, which should work and do most of what you want, but not necessarily do everything you want to do, or be fully polished or tuned. 

The presentation is a very short, 5-minute presentation in class on December 4-8.   Your presentation should clearly describe WHO you are, WHAT you did, HOW you did it, and WHY you chose to do it that way.  Bring a laptop to project your code, demo, slides, and/or figures, or email me your presentation materials the day before, if you'd like to present from my laptop.

The final code should be fully debugged, polished, tuned, commented, and include at least a short README explaining what it is, and what its results mean.  Style and clean code count!  Due Friday, December 15.  (This is scheduled after the presentation, so you can follow any suggestions or ideas you get during the presentation.)

Your final project grade is a multiplicative product of three factors:

• Ambition (or hubris) measures how much work you attempted.  A project with a high ambition score will attempt something significant but achievable.  A project with a low ambition score will attempt something trivial, like a 201 homework.
• Progress (or completion) measures how much you finished.  A project with a high progress score not only works, but includes a well-rounded set of features including a clear user interface, error checking, and self-checking.
• Comments (or style) measures how well the code is structured and documented.  To get a high grade, put clear high-level comments at the top of every file, document the major chunks of your code inline, and include a short clear README saying what the code does and why.  To get a low grade, use a haphazard comment style with poorly spelled sentence fragments, copy-and-paste big swaths of code instead of using small clean functions, and use comments primarily to mislead the reader or turn off chunks of non-working code.
  

Typical grade breakdown: project grade = 25% rough draft + 25% presentation + 50% final code

Example Project Topics

• Continue Project 1: make it faster, make it do something new, port it to a new machine, use a new language, etc
  
• Write or modify a program to do "something useful" in assembly language.  Useful things include:
• Interact with the user in classic CS 201 style.  This means lots of string processing, like gets and puts.
• Do anything interesting in assembly, like the bit rotate or bit-scan forward instructions.  Add a nice callable C++ interface.
• Switch between user-level threads.
• Create a PC Boot Block, which is actually just up to 512 bytes of 16-bit mode x86 machine code at the start of a (usually emulated) disk, that the (usually emulated) CPU loads and runs on startup.  Your boot block can do anything it wants to the machine at that point--it's effectively a tiny operating system! 
• Do something interesting with SSE.  Almost any code where different floats do different things is very interesting under SSE.
• Compute something interesting with multicore threads or the graphics card (CUDA).
  
• Use direct syscalls, signals, or mmap to do something weird to any program.
• Take off from any homework problem you like, and do something interesting with it.  
• Start with any interesting C++ program.  Disassemble it.  Figure out and add comments to each line of the disassembly--every time I do this, I learn things I didn't know that I didn't know!
• Benchmark and then tune the performance of any existing program, including a homework from this or another class.  No assembly code is needed, although reading the disassembly can help you understand performance!
• Design a new CPU instruction set, and write a little CPU emulator to execute that instruction set.  This is easier than it sounds!
• Embrace and extend some assembly-related code from the net--but be sure to cite your sources, so I can grade you on what you've added, not what you started from.
• Write or modify a program to do something high-performance in assembly language.

Or pick your own topic!  As long as it's related to assembly language, binary code, it's OK!