Course Goals

This course develops students' sense of what really happens when software runs, and an understanding that this question can be answered at several levels of abstraction, including the hardware architecture level, the assembly level, the C programming level, and the Java programming level. Although we focus on data representation, assembly, and C, this core is connected to higher levels (ie, how Java could be implemented), lower levels (ie, the general structure of a processor), and the role of the operating system (but not how it is implemented).

For computer science students wanting to specialize at higher levels of abstraction, this course could – in the extreme – be the only course they take that considers the "C level" and below. However, most will take a subset of Systems Programming (CSE333), Operating Systems (CSE451), Compilers (CSE401), etc.

For students interested in hardware, embedded systems, computer engineering, and computer architecture, this course is the introductory course after which other courses will delve both deeper (ie, into specific topics) and lower (eg, into hardware implementation, circuit design, etc.). Of particular interest are Introduction to Digital Design (CSE369), Design of Digital Circuits and Systems (CSE371), Introduction to Embedded Systems (CSE474), and Computer Architecture I (CSE469).

Course Themes

The course has four principal themes:

• Representation: How different data types (from simple integers to arrays of data structures) are represented in memory; how instructions are encoded; and how memory addresses (pointers) are generated and used to create complex structures.
• Translation: How high-level languages are translated into the basic instructions embodied in process hardware, with a particular focus on C and Java.
• Control Flow: How computers organize the order of their computations, keep track of where they are in large programs, and provide the illusion of multiple processes executing in parallel.

Course Learning Objectives

At the end of this course, students should be able to:

• Describe the multi-step process by which a high-level program becomes a stream of instructions executed by a processor;
• Describe the basic organization of the memory hierarchy and the effect of its parameters on system performance;
• Trace the execution of assembly code (x86-64), map the assembly to high-level language constructs, and write simple pieces of assembly programs;
• Write C code using pointers to create and manipulate data structures;
• Write (or rewrite) code to take advantage of the computer execution model to improve execution efficiency;
• Debug small-ish C and assembly programs using GDB;
• Perform basic navigation and file system operations in Linux using a terminal;
• Explain the basic role of an operating system in executing processes;
• Identify some of the ways that computers and their design principles affect society today.

Course Components

The course consists of the following elements:

• Pre-Lecture Reading: The main technical material will be introduced via interactive readings and check-in questions on the EdStem platform. These should be completed before engaging with lecture material.
• Lectures: This course is listed in the Time Schedule as "in-person", and attendance is highly encouraged. To assist you with managing your other responsibilities, however, lecture recordings and activities will be made available afterward; these materials should not be considered – and, indeed, are not – replacements for in-person attendance
• Homework (Online Assignments): There are approximately 20 online homework assignments, corresponding to most of the class sessions. These are intended to solidify the lesson concepts and are usually due at least two class sessions later, though they are intended to be completed before the next class session.
• Labs (Programming Assignments): There are 6 total labs, due roughly every other week. They must be completed on one of the Allen School-supported machines running linux. These assignments reinforce key concepts, and we will strive to have them be as practical as possible.
• Optional Reading: There will be corresponding optional readings from the recommended course textbook that correspond to lesson topics.
• Exams: There will be a midterm and a final exam; see the Exams page for more information.

We will try to ensure that the workload is typical for a 4-credit course; specifically, we expect you to spend 9-12 hours per week outside of the lectures. If we do not succeed, please let us know in whichever way you feel the most comfortable (eg, in-person, email, anonymous feedback) and explain which parts of the course are causing you to spend too much time non-productively.

Grading Policies

We will compute your course grade approximately as follows:

• Pre-Lecture Readings and In-Lecture Polls: 15%
• Homework: 20%
• Labs: 37%
• Midterm: 10%
• Final: 15%
• Message Board Participation: 3%

Lecture Polling

The in-lecture polls are designed to give you a chance to check your understanding of the material by applying it on-the-spot, as well as an opportunity to interact with your classmates. These are intended to be low-pressure and lenient, so the grading primarily reflects participation (i.e., your answer does not need to be correct) This quarter, we will be using EdStem to administer the polls. Please have it open during lecture, whether you are attending live or viewing a recording.

Participation on Message Board and In Lecture

Part of your grade will be determined by your participation on the Ed message board. We are looking not just whether you ask questions, but also whether you answer questions and read posts from others. Please note that posting anonymously on Ed is fine! Your identity will be unknown to other students in the course, but not to the staff.

In-person participation can be tricky to assess equitably, so we do not attempt to do so. We still strongly encourage in-person participation, even though we will not grade it, as it is positively correlated with higher scores in other categories (eg, final exam).

Assignment Policies

• Pre-Lecture Readings (on Ed) have quiz questions and are counted (not graded) on completion; late submissions are NOT allowed. After submitting an answer, you are encouraged to revisit your work and submit again, though you can also reveal the correct answer. Readings are intended to be done before your lecture, and are due at 11:00am (ie, 30 min before the start of Lecture A). Answering ~80% of the questions should get you full credit for this portion of your course grade.
• Lecture Polling Questions (on Ed) are counted (not graded) on completion; late submissions are NOT allowed. Solutions will be covered during class session and the correct answer will be displayed after the deadline. As with pre-lecture readings, answering ~80% of the questions should get you full credit for this portion of your grade.
• Homework (Online assignments) (on Ed) are graded automatically (eg, using grading scripts); late submissions are NOT allowed. You are allowed an unlimited number of attempts for each quiz and you will receive credit for every question that you answer correctly. In recognition of the fact that learning involves learning from mistakes, we will drop your lowest homework score at the end of the quarter.
• Labs (Programming assignments) are submitted by uploading files to Gradescope. Late lab submissions are subject to the late day policy described below. Labs are graded by a combination of grading scripts and TAs.
• Exams are "take-home" and must be completed within the allotted window of time. See the calendar or the Exams page for dates. Exams are graded by the staff and will be handled via Gradescope.

Late Day Policy

There are absolutely no late submissions accepted for readings, polls, homework, or exams.

We expect labs to be submitted on time; however, we realize that our deadlines may occasionally overlap with another class's, or that work may schedule you for an unexpected shift. In recognition of this fact, you are allowed a total of 5 late day tokens. A late day is defined as the 24-hour period after a due date (ie, num_late_days = ceil(hours_late / 24)). Typically, you may spend up to 2 tokens per assignment, though some assignments may adjust this threshold up or down.

For each late day you use that exceeds the tokens, you will be penalized 10% of your score on one of the late assignments. The penalties will be applied in a manner that maximizes your overall grade (ie, minimizes your total penalties). No individual assignment will be penalized more than twice.

We consider late day tokens as an optional tool for managing your time; if CSE 351 were your only class and your only job, you wouldn't use them at all. For this reason, unused late days have no impact on your grade at the end of the quarter; on the other hand, if you exceed the tokens you will be penalized 10% of your score on a late assignment. The penalties will be applied in a manner that maximizes your overall grade (ie, minimizes your total penalties), and no individual assignment will be penalized more than twice.

Inclusiveness

Our code and our projects are made better by considering a variety of viewpoints. Your course staff is committed to the values outlined in the Allen School's inclusiveness statement, and you are expected to uphold a supportive and inclusive learning environment.

If, at any point, you are made to feel uncomfortable, disrespected, or excluded by a staff member or fellow student, please report the incident so that we may address the issue and maintain a supportive and inclusive learning environment. Should you feel uncomfortable bringing up an issue with a staff member directly, consider sending anonymous feedback or contacting the Office of the Ombud.

Academic Conduct

Learning these ideas is challenging. We encourage you to discuss course activities with your friends and classmates as you are working on them, because you will learn more in this class if you work with others than if you do not. Ask questions, answer questions, and share ideas liberally; we want a class that is open, welcoming, and collaborative, where we can help each other build the highest possible understanding of the course material.

Learning collaboratively is different from sharing answers. Ultimately, the difference between collaboration and sharing answers boils down to "whose brain generated the submission?". A good rule-of-thumb for distinguishing between these two is this: "Can I, or my collaborator, attempt an immaterially-different question (eg, allocating an integer instead of a double), by myself/themself?". If the answer is "yes", then someone learned from your collaboration; that’s great! Please do more of it! Go you!

However, if the answer to this question is “no”, then you were sharing answers. Please don't do that. In particular:

• Do not use any collaboration-generated materials (eg, code, notes, or screenshots) when you are working on the materials that you will submit for grading. You MAY NOT ALLOW your collaborators to take away materials, either.
• Cite the names of all your collaborators, regardless of whether they are currently enrolled in CSE 351.
• Take a 30 minute break (eg, go for a run, watch a TV show, wash the dishes) before writing up the solution that you will submit for grading.
• Treat coding assistants and generative AIs (eg, Github Copilot, OpenAI ChatGPT) as if they were another human; you may "discuss" class problems with these tools (eg, ask them to write an additional example or to explain code that you wrote), but your submitted work must comply with the above (ie, be written independently and without referencing any output from that tool). Additionally, you must cite both the specific coding assistant(s) and also the prompts that you used.

Ultimately, YOU are the one who is responsible for understanding and applying the school's Academic Misconduct Policy, which applies to students who provide answers in addition to those receiving them. If you are in doubt about what might constitute misconduct, contact the course staff describing the situation and we will be happy to clarify it for you. When it comes to the potential for sharing answers, it is better to ask permission than to beg forgiveness.

Disability Resources

The Disability Resources for Students (DRS) is a unit within the Division of Student Life and is dedicated to ensuring access and inclusion for all students with disabilities on the Seattle campus. They offer a wide range of services for students with disabilities that are individually designed and remove the need to reveal sensitive medical information to the course staff. If you have a medical need for extensions of exam times or assignment deadlines, these will only be granted through official documentation from DRS. See the Getting Started page to start the process as soon as possible to avoid delays.

Religious Accommodations

Washington state law requires that UW develop a policy for accommodation of student absences or significant hardship due to reasons of faith or conscience, or for organized religious activities. The UW's policy, including more information about how to request an accommodation, is available at Religious Accommodations Policy. Accommodations must be requested within the first two weeks of this course using the Religious Accommodations Request form.

Extenuating Circumstances

We recognize that our students come from varied backgrounds and can have widely-varying circumstances. If you have any unforeseen extenuating circumstance that arises during the course, please do not hesitate to contact the staff to discuss your situation. The sooner we are made aware, the more easily we can help. Extenuating circumstances may include:

• Work-school balance
• Familial responsibilities
• Military duties
• Unexpected travel
• Acute health issues (notably: recall mental health is still health)
• Concerns about personal safety
•  
• ... or anything else beyond your control which may negatively impact your performance