This is the SPO600 tentative course schedule. It's a live document and will be revised throughout the semester. Each topic will be linked to notes at the end of this page as the course proceeds.

Classes marked Async will be delivered in asynchronous online mode.

• 2025 Winter Participants

• Edited summary video

Note: these summary videos are no substitute for attending class in-person! They do not include: quizzes and quiz answer discussion, group exercises, and group discussion. It may take several days to process and edit the video before it is made available. It may not record properly and may not be made available. Do not rely only on the summary videos!

• Course resources are linked from this wiki.
• Coursework is submitted by blogging. The only exception to this is quizzes.
• Quizzes will be short (equivalent to ~1 page) and will be held without announcement at the start of any synchronous class. The quizz answers will be discussed immediately after submission. There is no opportunity to re-take a missed quiz, but your lowest three quiz scores will not be counted, so do not worry if you miss a few.
  • Students with test accommodations: alternate quizzes can be made available via the Test Centre. Communicate with your professor for details.
• Course marks (see Weekly Schedule for dates):
  • 60% - Project Deliverables in three phases (15%, 20%, 25%)
  • 20% - Communication (Blog writing, in four phases, 5% each)
  • 10% - Labs
  • 10% - Quizzes (lowest 3 quiz scores not counted)

• Online Classes
  • Synchronous: Tuesday and Friday 8:00-3:15 pm. Attendance at the Tuesday classes is mandatory.
    • Summary video(s) may be posted on a best-effort basis (technical issues may prevent posting in some cases). The summary video will be edited and will not include all of the content covered in class. The link(s) to the video(s) will be posted on this page under the corresponding date. The video will not cover all of the synchronous session, and may not be posted if there are any technical issues with the recording. Do not rely on the summary videos.
  • Asynchronous: Resources will be released by Thursday 1:30 pm. You are expected to review and learn this material before the following class (the next Tuesday).
  • Please attend the online sessions and take lots of notes.

Most software is written in a high-level language which can be compiled into machine code for a specific computer architecture. In many cases, this code can be compiled or interpreted for execution on multiple computer architectures - this is called 'portable' code.

However, there is a lot of existing code that contains some architecture-specific code fragments which contains assumptions about the architecture, resulting in architecture-specific high-level or Assembly Language code. This code must be 'ported' or adapted to work on other platforms.

Reasons that code is architecture-specific:

• System assumptions that don't hold true on other platforms
  • Variable or word size
  • Endianness
  • Memory ordering
  • Specific machine details, such as memory page size, stack order, or edge-case floating-point behavior
• Code that takes advantage of platform-specific features

Reasons for writing code in machine-specific Assembly Language include:

• Performance
• Atomic Operations
• Direct access to hardware features, e.g., CPUID registers

Most of the historical reasons for using assembler are no longer valid. Modern compilers can out-perform most hand-optimized assembly code, atomic operations can be handled by libraries or compiler intrinsics, and most hardware access should be performed through the operating system or appropriate libraries.

A new architecture has recently appeared: AArch64, which is a 64-bit execution state introduced as part of Arm architecture version 8 (ARMv8). This is the first new computer architecture to appear in several years (at least, the first mainstream computer architecture).

At this point, most key open source software (the software typically present in a Linux distribution such as Ubuntu or Fedora, for example) now runs on AArch64. However, it may not yet be as extensively optimized as on older architectures (such as x86_64).

An additional architecture is on the horizon: Risc-V (pronounced “Risk-Five”). This is an experimental architecture which is open-source and may provide a competitive alternative to ARM and other architectures in the future.

Optimization is the process of evaluating different ways that software can be written or built and selecting the option(s) that has the best performance tradeoffs for the situation at hand.

Optimization may involve substituting software algorithms, altering the sequence of operations, using architecture-specific code, selecting data types, or altering the build process. It is important to ensure that the optimized software produces correct results and does not cause an unacceptable performance regression for other use-cases, system configurations, operating systems, or architectures.

Optimization is tied to the concept of Portability because optimization techniques vary according to the details of the target architecture.

The definition of “performance” varies according to the target system and the operating goals. For example, in some contexts, low memory or storage usage is important; in other cases, fast operation; and in other cases, low CPU utilization or long battery life may be the most important factor. It is often necessary to trade off performance in one area for another; using a lookup table, for example, can reduce CPU utilization and improve battery life in some algorithms, in return for increased memory consumption.

Virtually all compilers (and interpreters) perform some level of optimization, and the options selected for compilation can have a significant effect on the trade-offs made by the compiler, affecting memory usage, execution speed, executable size, power consumption, and debuggability.

However, there are some types of optimization that cannot be applied by the compiler, and which must be applied by the programmer.

Building software is a complex task that many developers gloss over. The simple act of compiling a program invokes a process with five or more stages, including pre-processing, compiling, optimizing, assembling, and linking. However, a complex software system will have hundreds or even thousands of source files, as well as dozens or hundreds of build configuration options, auto configuration scripts (cmake, autotools), build scripts (such as Makefiles) to coordinate the process, test suites, and more.

The build process varies significantly between software packages. Most software distribution projects (including Linux distributions such as Ubuntu and Fedora) use a packaging system that further wraps the build process in a standardized script format, so that different software packages can be built using a consistent process.

In order to get consistent and comparable benchmark results, you need to ensure that the software is being built in a consistent way. Altering the build process is one way of optimizing software.

Note that the build time for a complex package can range up to hours or even days!

Benchmarking involves testing software performance under controlled conditions so that the performance can be compared to other software, the same software operating on other types of computers, or so that the impact of a change to the software can be gauged.

Profiling is the process of analyzing software performance on finer scale, determining resource usage per program part (typically per function/method). This can identify software bottlenecks and potential targets for optimization. The resource utilization studies may include memory, CPU cycles/time, or power.

Follow the instructions on the SPO600 Communication Tools page to set up a blog, create SSH keys, and send your blog URLs and public key to me.

I will use this information to:

1. Update the Current SPO600 Participants page with your information, and
2. Create an account for you on the SPO600 Servers, if you didn't do that during class.

The updating is done in batches every few days – allow some time!

• Edited Summary Video

• Background knowledge
  • Computer Architecture basics
  • Machine Language vs Assembly Language
  • Assembler Basics
• 6502 - Basic information about the processor
• 6502 Addressing Modes
• 6502 Instructions
• 6502 Emulator documentation
  • Emulator online

• Lab 1 - 6502 Assembly Language Lab

• Set up your SPO600 Communication Tools
• Start your Lab 1 and blog about it.

This is an asynchronous class - there is no live meeting.

• Pre-recorded video: Binary Representation of Data (from Summer 2024)

This is an asynchronous class - there is no live meeting.

• Pre-recorded video: Architectures, Micro-Architectures, and Compiler Options

• Complete your Lab 1 (and blog about it!).