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. Mon, Aug 29

   The language hierarchy: from electrons to web pages

2. Wed, Aug 31

   Assembly language syntax

3. Fri, Sep 02

   Looping and branching in assembly language

   • HW0: review of C++

4. Mon, Sep 05

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

5. Wed, Sep 07

   Function calls in assembly language

6. Fri, Sep 09

   Deadline for adding classes and late registration; 5 p.m. in person, midnight at UAOnline

7. Fri, Sep 09

   Last day for student- and faculty-initiated drops (course does not appear on academic record)

8. Fri, Sep 09

   Register sizes and the stack

   • HW1: basics of assembly

9. Mon, Sep 12

   Deadline for tuition and fee payment and refunds; 5 p.m. in person, midnight at UAOnline

10. Mon, Sep 12

    Memory addresses and data declarations

11. Wed, Sep 14

    Arrays, addresses, and strings

12. Fri, Sep 16

    Memory allocation: static, stack, and malloc

    • HW2: function calls

13. Mon, Sep 19

    Structs and classes in assembly

14. Wed, Sep 21

    Linked data structures

15. Fri, Sep 23

    printf: formatted output in plain C or assembly

    • HW3: memory allocation

16. Mon, Sep 26

    Inline assembly language in C++ code

17. Wed, Sep 28

    Machine code: x86 vs ARM

18. Fri, Sep 30

    The Linker

    • HW4: inline and machine code

19. Mon, Oct 03

    Bits, signed numbers, and bitwise operators

20. Wed, Oct 05

    Floating point numbers

21. Fri, Oct 07

    Floating point in x86 assembly language

    • HW5: floating point

22. Mon, Oct 10

    Course review for midterm exam

23. Wed, Oct 12

    Midterm exam in class

24. Fri, Oct 14

    Project 1 presentations

25. Mon, Oct 17

    Project 1 presentations cont'd

26. Wed, Oct 19

    Performance programming intro: nanoseconds and nanojoules

27. Fri, Oct 21

    Memory cache, locality and performance

    • HW6: performance tuning

28. Mon, Oct 24

    SIMD: Parallel floating point with SSE

29. Wed, Oct 26

    Multicore via OpenMP kernel threads

30. Fri, Oct 28

    Graphics Processing Unit (GPU) programming via CUDA

    • HW7: SSE, OpenMP, GPU

31. Mon, Oct 31

    Security: memory protection with mmap

32. Wed, Nov 02

    Security: signals and the OS call interface

33. Fri, Nov 04

    Last day for student- and faculty-initiated withdrawals (W grade appears on academic transcript)

34. Fri, Nov 04

    Security: buffer overflow attacks

    • HW8: security boundaries

35. Mon, Nov 07

    Embedded systems programming: arduino intro

36. Wed, Nov 09

    Embedded systems: registers and wires

37. Fri, Nov 11

    Embedded systems security and power attacks

    • HW9: embedded systems

38. Mon, Nov 14

    Begin registration and fee payment for spring 2017 semester and WINTERmester 2017

39. Mon, Nov 14

    Systems programming: macros

40. Wed, Nov 16

    Systems programming: registration and tables

41. Fri, Nov 18

    Systems programming: multithread designs

42. Mon, Nov 21

    Systems programming in depth: the linux kernel

    • HW10: systems programming

43. Wed, Nov 23

    Optional pre-thanksgiving lecture: quantum computing

44. Thu, Nov 24

    Thanksgiving holiday (no classes, most offices closed)

45. Fri, Nov 25

    No class due to thanksgiving

46. Mon, Nov 28

    Architecture: ARM instruction set

47. Wed, Nov 30

    Architecture: 16 bit x86 code & the BIOS

48. Fri, Dec 02

    Architecture: biological computing

    • HW11: ARM

49. Mon, Dec 05

    Project 2 presentations

50. Wed, Dec 07

    Project 2 presentations cont'd

51. Fri, Dec 09

    Course review for midterm exam

52. Wed, Dec 14

    Final exam, 10:15-12:15pm

Grading Policies

Grades will be assigned based on the following percentage intervals:

A+

[97%, 100%)

A

[93%, 97%)

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.