CS301 Assembly Language Programming

3 + 0
  • CS201
Orion Lawlor
Chapman 201E
Office Hours
Meeting Time
Chapman 104
Course Website
Required Texts
No text is required--readings will be available online

Course Description

Describes how your code executes on real hardware, which is key to debugging, security, and performance. Includes details on both assembly language, such as registers and opcodes, and plain C programming, such as pointer arithmetic and malloc.

Course Outcomes

  • Ability to measure actual performance on a given architecture
  • Ability to optimize the performance of a program

Tentative Schedule

    • NetRun intro, language hierarchy: Assembly through JavaScript
    • Labor Day (offices closed — no classes, registration or fee payment)
    • Machine code, assembly language, and registers
    • Goto, loops and branches in assembly (add deadline)
      • hw0 on C++ background due
    • Stack push and pop
    • Functions and preserved registers
    • C strings and char arrays, and static memory with db (drop deadline)
    • Static memory allocation with dd and dq
    • Pointers and pointer arithmetic
    • Pointer chasing and linked lists
    • C memory allocation: malloc, speed of malloc versus stack allocation
    • C structs and C++ classes in assembly; sizeof and offsetof
    • JavaScript runtime typed objects
    • Function pointers and virtual/vtable methods
    • Tables, switch statements, and computed branches
    • JavaScript anonymous functions and closures
    • C and Assembler macros: preprocessor defines, include guards
    • Inline assembly language
    • Linker: extern "C" and C++ name mangling
    • Course review for midterm exam
    • Midterm exam
    • Performance optimization: working around timer granularity
    • Project 1 presentations
    • Project 1 presentations (cont'd)
    • Performance basics: cost of operations in Assembly, C, C++, JavaScript
    • Bits, signed versus unsigned numbers, and comparisons (withdrawal deadline)
    • SIMD within a Register (SWAR), and bitwise operators
      • Project 1 final draft due
    • Bits in a floating-point number, and float roundoff
    • SSE: Floating-point arithmetic in assembly
    • SSE: Parallel floating-point in assembly
    • SSE performance analysis
    • Security: stack smashing attacks and defenses (NX bit)
    • Security: programming with ROP gadgets
    • Security: user and kernel permissions
    • Embedded systems programming survey
    • Optional lecture on quantum computing
    • Thanksgiving holiday (no classes, most offices closed)
    • Memory performance and cache
    • mmap and the CPU page table
    • Memory-mapped I/O on embedded systems
    • GPU programming and performance: coding with a million threads
    • Project 2 presentations
      • Project 2 final draft due
    • Project 2 presentations cont'd
    • Course review for final exam (last day of class)
    • Final exam, 10:15am-12:15pm

Grading Policies

Weight Description
5% Attendance and class participation, graded at random intervals throughout the semester
15% Project 1, an independent project, typically due near the time of the Midterm exam
15% Project 2, an independent project due near the Final exam
20% Final exam (cumulative)
20% Midterm exam, held in mid-October
25% Homework problems, to be assigned through the semester

Grades will be assigned based on the following percentage intervals:

[99%, 100%)

[93%, 99%)
[90%, 93%)
[87%, 90%)

[83%, 87%)
[80%, 83%)
[77%, 80%)

[73%, 77%)
[70%, 73%)
[67%, 70%)

[63%, 67%)
[60%, 63%)
[0%, 60%)

How To Succeed In This Course

The low-level programming we'll be doing in this course consists of dozens of features that are individually trivial, yet collectively are famously error-prone.  Careful attention to detail, and systematic scientific testing and debugging, are the keys to mastering it.

  • What makes the code crash?  I will often comment out key functionality in the program, with the explicit goal of measuring how the program's results change, even if the modified program is completely useless at the problem I'm trying to solve.  Understanding the crash is what leads me to a working program later on.
  • When did the code start crashing?  I always work incrementally, starting with the simplest possible program (such as "return 5"), and adding small features one at a time.  If you just added the print function, and the code starts crashing, it's much easier to debug than if you write everything first, then run the complete program.  I try to structure homeworks so you are forced to build the code up incrementally.
  • How does the code crash?  I will often change code to force a crash earlier, to collect more data on the state of the machine leading up to the real crash.
  • Which assumption is incorrect?  Programs fail because you don't understand something.  The goal is to narrow this down until you know what part you don't understand, so you can run more experiments or collect more data (or ask Dr. Lawlor) until you do understand it.
  • What have we learned so far?  In a long debugging session, it is very easy to lose track of what you've determined from each experiment.  I almost always have a text editor open where I paste in code snippets, experimental results, and free text with lessons learned, so I can see I'm making progress.

Your brain condition is also key:

  • Are you correctly fed and hydrated?  The brain is a liquid computer that runs on glucose, and automatically throttles down your higher brain functions when blood sugar is off nominal. 
  • Are you angry or upset?  It is common to feel anger when your programs are not working, which does not help you understand why your programs are not working.  The appropriate emotional response to the wrong output or a crash is "Ah ha!  An interesting mystery.  Let us begin the search for clues!" rather than "OH NO!  WHY DID THIS HAVE TO HAPPEN!?  WHY DOES C++ HATE ME?!".  A perfect recipe for rage-soaked terror is waiting until the last minute.
  • Is your study environment free of distracting inputs?  The human brain is surprisingly poor at multitasking, which means minor distractions like incoming text messages can have a large impact on your ability to see what the program is telling you.
  • Have you had enough sleep?  Many key brain maintainance functions are only run while offline, including learning.  
  • Are you sober?  Many psychoactive substances degrade higher-level brain function for days, much longer than their acute effects.  Even mild psychoactive substances such as sugar or caffeine can disrupt the high-intensity mental work of programming. 

I personally find programming and even debugging to be a refreshingly zen experience, where I am so immersed in the task that the entire outside world fades away ("flow" or "being in the zone").  

Late Work Policy

Late work will not be graded, unless it is due to circumstances beyond your control, or if you turn it in before I begin grading. I may begin grading at any time after the due date, even 12:01am the next day. You are encouraged to inquire if I have begun grading yet, since this acts as a reminder for me to do so!


Students are expected to be at every class meeting on time, and are responsible for all class content, whether present or not. If absence from class is necessary, in-class work (other than quizzes) and homework may be made up only if the instructor is notified as soon as possible; in particular, absences due to scheduled events must be arranged ahead of time. Academic dishonesty will not be tolerated, and will be dealt with according to UAF procedures. Students in this class must pay the CS lab fee. Payment allows access to the Chapman 103 lab.

UAF academic policies http://www.uaf.edu/catalog/current/academics

CS Department policies http://www.cs.uaf.edu/departmental-policies/

Disabilities Services:

The UAF Office of Disability Services implements the Americans with Disabilities Act (ADA), and ensures that UAF students have equal access to the campus and course materials. I will work with the UAF Office of Disability Services (208 WHITAKER BLDG, 474-5655) to provide reasonable accommodation to students with disabilities.