Intro to Computer Systems

CMPT 295, Summer 2026

Greg Baker

https://ggbaker.ca/295/

This Course

It's Introduction to Computer Systems. It contains both computer systems and computer organization concepts. (More later.)

Course web site: in CourSys, https://coursys.sfu.ca/2026su-cmpt-295-d1/pages/ .

If you're on the waiting list: I have no control over it. You're welcome to attend lectures for the first week or so until it's sorted out.

This Course

Instructor: Greg Baker.

Office hour: Wednesdays 12:00–13:00 and Fridays 2:30-3:30 in CSIL (ASB 9700).

This Course

Whoever you are, I'm glad you're here.

Progress Pride flag Every Child Matters logo Black Lives Matter logo

This Course

TAs:

  • Mohammad
  • Aditya
  • Sedi
  • Mohammadhossein

Lab coverage to be announced.

This Course

Outside of office hours, the discussion forum is the best place for questions.

This Course

Greg's honest order of priority when dealing with student queries:

  1. In-person questions in CSIL, etc.
  2. Public questions in the discussion forum.
  3. Anything else that helps >1 student.
  4. Private questions in the discussion forum.
  5. Email.

Grading

  • Weekly lab assignments: 12 × 2% = 24%
  • Mini-project: 6%
  • Quizzes: 2 × 15% = 30%
  • Final Exam: 40%

Lectures and Labs

Lectures: as scheduled, in-person. Audio recordings (hopefully). Note different room for Wednesday and Friday.

Labs: as-scheduled, in-person, in CSIL (ASB 9700). Attendance required. Submitted online.

No lab this week (week 1), but every other week (weeks 2–13).

Lectures and Labs

The lab assignments will be fairly short, but likely need >1 hour to complete.

My suggestion: since the labs are all on Friday, start them before the lab and come with your final questions/​problems/​refinements. Then finish before the midnight submission deadline.

Mini-Project

The weekly lab exercises are necessarily small and self-contained. They will focus on individual concepts.

The project is designed to force you to integrate the ideas of the course (while still being relatively small for a project).

Mini-Project

Rough idea: take some code (from a textbook, excerpted from open source projects, written by you, etc) and evaluate them with respect to the concepts we covered in the course. Possibly try to improve it (but probably fail, because code from an established project probably doesn't have a lot of obvious places to improve).

Mini-Project

Write a 2–3 page report summarizing what you found.

The last stuff you definitely need for the project is the Tools slides, so worry about it around then.

Quizzes/Exams

The quizzes will be during the lecture time:

  • June 24 (Wednesday of week 7)
  • July 22 (Wednesday of week 11)

The final exam will be whenever/​wherever Student Services schedules it.

References

There is no required textbook for this course.

Possible reference material:

Assumptions

  • You were paying attention in the prerequisite courses.
  • You are a reasonably competent C or C++ programmer: variables, control structures, functions, using library code.
  • Specifically: references and heap-allocated instances (new/​delete) in C++ or pointers and heap allocation (malloc/​free) in C.
  • Basics of a Linux command line. At least minimal fear of a command line.

Expectations

To get credit for this course, I expect you to demonstrate that you know the basic knowledge and skills of the course. That means:

  • A pass on the weighted average of the stuff where you demonstrate hands-on skills: lab exercises and project.
  • A pass on the weighted average of the quizzes and final exam.

Failure to do these may result in failing the course.

Expectations

That rule isn't intended to fail someone just because they get 49% on the exams: it will be applied on an individual basis with a judgement call on the question has this student has demonstrated that they understand the basic concepts of the course?

Expectations

Academic Honesty: it's important, as always. All code you submit must be created by you, not somebody else, and by hand not with some code-generating tool.

If we can tell where your code came from (another student or some tool), then it's too close to that source. Proposed rule for avoiding this: don't look at others' code and write your code at the same time.

Expectations

Examples of things that are not okay and will be treated as academic dishonesty:

  • Using a tool to create some code and cleaning it up a little, or having a tool fix your code.
  • Finding a solution (online or from your friend), looking at it until you really, really understand it, changing enough you think I won't notice the similarity, and submitting it.
  • Sitting beside your friend and creating a single solution together, even though you're touching different keyboards.

Expectations

Working through the assigned problems is a lot of the way you're going to learn the course material. Think about labs as opportunities for learning, not for marks.

Expectations

If you're copying a solution from online, it's academic dishonesty.

If you're using a code fragment from online source (in a reasonable way where permitted by the assignment), leave a comment.

// code adapted from http://stackoverflow.com/a/...
void do_the_thing(int n) {
    ...
}

Expectations

The quizzes and exam are regular tests: individual work, closed book.

I will be asking for a grade of FD in the course for any academic dishonesty on tests.

Expectations

For the quizzes and final, I will consider it academic dishonesty to have any of these in any way available to you (including in your pocket, within arm's length, under your seat, etc): phone, smart watch, smart glasses, smart ring, calculator, fitness tracker, earbuds, smart anything else that can be used to communicate or connect to the internet.

Yes, even if you promise you didn't use it. [If you have a medical device that might fall into that category, let me know before the exam.]

Computer Systems

So, what are we actually doing in this course?

Or, why is this a required course?

Computer Systems

Be honest, what's your answer to how does the code you write actually run?

My predictions…

  • I press F5.
  • The compiler… something something.
  • Visual Studio… does it?
  • I write code. Computer go brrr.

Those aren't actually bad answers: it's possible to be a good programmer without knowing much about how a computer actually runs your logic.

Computer Systems

But there's a lot between your code and the computer.

how code runs

Computer Systems

Many details are abstracted away from you between the editor window and the circuits that are doing the work.

That's usually okay, but there are times knowing them will let you write better code.

Computer Systems

For example, some statements that I believe are true. You should know why (and/or be able to argue that I'm wrong).

  • Linked lists are (ususally) bad.
  • I (almost) never write a C-style for loop.
  • Single-threaded code is slow code.

Computer Systems

These topics lead us to the boundary where the unavoidable realities of hardware meet software.

Being able to peek across those abstractions will guide you to writing better code, or understanding problems when they arise.

Hardware

Many of the things we need to do (most notably, assembly programming) are specific to the CPU architecture of the machine where it's going to run.

The details are different between ARM, x86, RISC-V, etc (but the basic concepts are the same).

Hardware

We will be writing assembly code for the x86-64 architecture. This describes systems based on mainstream Intel or AMD CPUs after about 2005.

Synonyms of x86-64: x64, AMD64, Intel 64.

Hardware

Specifically, you need access to something slightly modern: an Intel Haswell (∼2013, Intel Core 4xxx) or later or AMD Zen (Ryzen/​Epyc) CPU.

That describes all CSIL workstations and any computer that is less than about 12 years old.

Hardware

Does Apple Silicon with emulation meet that criteria? Maybe… probably… often? [I don't have one.]

Most of your work can definitely be done in a Linux VM. There may be some problems where real hardware is necessary: remoting into CSIL would be the best solution then.

Hardware

All examples will be in Linux. All submitted code must work in Linux. You should work in Linux.

No support can be provided for anything else, and many of the tools we need aren't available anywhere else.

tl;dr Linux.

But, same answer about VMs (including WSL): usually okay but sometimes a real-hardware test might be needed.

Hardware

There will be many examples in C (and C++) in this course. You have probably been working with C++. C is not a subset of C++, but it's close.

There's nothing special about C here: I can imagine a different CMPT 295 that uses Rust or any language that has a good machine code compiler.

I'll try to say C and C or Rust or something as appropriate, but will probably usually forget.

Hardware

Basically: in some alternate universe, I'm teaching this course with Rust on ARM. The topics, themes, and learning outcomes would be the same.

In this universe: x86-64 and C.

Topics (1)

  • Computer architecture: the parts of a computer, what they're for, and how they interact
  • Assembly programming
  • C vs assembly
  • Representing information in binary

Topics (2)

  • Memory architecture
    • cache, memory, virtual memory
  • CPU tricks
    • vector processing
    • pipelining
    • branch predictionm
  • Compiler optimization and hand-optimizing code
  • Concurrent and parallel code

Topics (3)

Why do I care about any of this?

Running code has a cost, no matter what: in time, electricity, battery life, CO2 emissions, cloud provider bills, etc. Seeing through some of these abstractions let you write better code that's cheaper (in whatever way).