CS301 Assembly Language Programming

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

1. Fri, Sep 04

   NetRun intro, language hierarchy: Assembly through JavaScript

2. Mon, Sep 07

   Labor Day (offices closed — no classes, registration or fee payment)

3. Wed, Sep 09

   Machine code, assembly language, and registers

4. Fri, Sep 11

   Goto, loops and branches in assembly (add deadline)

   • hw0 on C++ background due

5. Mon, Sep 14

   Stack push and pop

6. Wed, Sep 16

   Functions and preserved registers

7. Fri, Sep 18

   C strings and char arrays, and static memory with db (drop deadline)

8. Mon, Sep 21

   Static memory allocation with dd and dq

9. Wed, Sep 23

   Pointers and pointer arithmetic

10. Fri, Sep 25

    Pointer chasing and linked lists

11. Mon, Sep 28

    C memory allocation: malloc, speed of malloc versus stack allocation

12. Wed, Sep 30

    C structs and C++ classes in assembly; sizeof and offsetof

13. Fri, Oct 02

    JavaScript runtime typed objects

14. Mon, Oct 05

    Function pointers and virtual/vtable methods

15. Wed, Oct 07

    Tables, switch statements, and computed branches

16. Fri, Oct 09

    JavaScript anonymous functions and closures

17. Mon, Oct 12

    C and Assembler macros: preprocessor defines, include guards

18. Wed, Oct 14

    Inline assembly language

19. Fri, Oct 16

    Linker: extern "C" and C++ name mangling

20. Mon, Oct 19

    Course review for midterm exam

21. Wed, Oct 21

    Midterm exam

22. Fri, Oct 23

    Performance optimization: working around timer granularity

23. Mon, Oct 26

    Project 1 presentations

24. Wed, Oct 28

    Project 1 presentations (cont'd)

25. Fri, Oct 30

    Performance basics: cost of operations in Assembly, C, C++, JavaScript

26. Mon, Nov 02

    Bits, signed versus unsigned numbers, and comparisons (withdrawal deadline)

27. Wed, Nov 04

    SIMD within a Register (SWAR), and bitwise operators

    • Project 1 final draft due

28. Fri, Nov 06

    Bits in a floating-point number, and float roundoff

29. Mon, Nov 09

    SSE: Floating-point arithmetic in assembly

30. Wed, Nov 11

    SSE: Parallel floating-point in assembly

31. Fri, Nov 13

    SSE performance analysis

32. Mon, Nov 16

    Security: stack smashing attacks and defenses (NX bit)

33. Wed, Nov 18

    Security: programming with ROP gadgets

34. Fri, Nov 20

    Security: user and kernel permissions

35. Mon, Nov 23

    Embedded systems programming survey

36. Wed, Nov 25

    Optional lecture on quantum computing

37. Thu, Nov 26

    Thanksgiving holiday (no classes, most offices closed)

38. Mon, Nov 30

    Memory performance and cache

39. Wed, Dec 02

    mmap and the CPU page table

40. Fri, Dec 04

    Memory-mapped I/O on embedded systems

41. Mon, Dec 07

    GPU programming and performance: coding with a million threads

42. Wed, Dec 09

    Project 2 presentations

    • Project 2 final draft due

43. Fri, Dec 11

    Project 2 presentations cont'd

44. Mon, Dec 14

    Course review for final exam (last day of class)

45. Fri, Dec 18

    Final exam, 10:15am-12:15pm

Grading Policies

Grades will be assigned based on the following percentage intervals:

A+

[99%, 100%)

A

[93%, 99%)

A-

[90%, 93%)

B+

[87%, 90%)

B

[83%, 87%)

B-

[80%, 83%)

C+

[77%, 80%)

C

[73%, 77%)

C-

[70%, 73%)

D+

[67%, 70%)

D

[63%, 67%)

D-

[60%, 63%)

F

[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!

Policies

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.

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.