Intro to Computer Systems

CMPT 295, Summer 2024

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/2024su-cmpt-295-d1/pages/ .

This Course

Instructor: Greg Baker.

Office hour: Wednesdays 3:30–4:20 and Fridays 1:30-2:20 in CSIL (ASB 9838). [Except week 1 when CSIL is closed: in TASC1 9229 this week.]

This Course

TAs: to be announced.

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. Private questions in the discussion forum.
  4. Email.

This Course

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

Progress Pride flag Every Child Matters logo Black Lives Matter logo

Grading

  • Weekly lab assignments: 12 × 2.5% = 30%
  • Mini-project: 8%
  • Quizzes: 2 × 12% = 24%
  • Final Exam: 38%

Lectures and Labs

Lectures: as scheduled, in-person. Audio recordings (hopefully).

Labs: as-scheduled, in-person, in CSIL (ASB 9838). 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: at least review them and get started before your lab time; go the lab and ask any questions/​clear up the details; finish before the Friday 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 piece of 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).

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

Quizzes/Exams

The quizzes will be during the lecture time:

  • June 14 (Friday of week 6)
  • July 12 (Friday of week 10)

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, cleaning it up a little, and submitting it.
  • 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 exams are individual work, closed book.

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

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.

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 bad.
  • The C-style for loop is bad.
  • 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 10 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