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

See the SPO600 2024 Fall Participants page.

• Edited summary video

Note: these summary videos are no substitute for attending class in-person! It does 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 (Tuesday) 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 one or two.
  • 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 1:30-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.
• 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 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).

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.

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!

The 6502 Processor is a simple 8-bit processor that powered a number of early microcomputers (and video games). We're going to use it to learn machine language and assembly language concepts before tackling modern processors (because the 6502 instruction set can be documented in one page rather than 7000 pages!).

• 6502 - Basic information about the processor
• We'll continue exploration of this processor in the next class…

Due to a power + Internet outage, these videos are from a previous semester.

• Binary Representation of Data
• Computer Architecture & the 6502 (Starter) - Ignore the comments at the end about the course format and schedule, they are applicable only to the previous semester.

* Set up your SPO600 Communication Tools

• Edited Summary Video

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

• Lab 1 - 6502 Assembly Language Lab

• 6502 Math
• 6502 Flow Control (Jumps, Branches, and Subroutines)

• 6502 Jumps, Branches, and Procedures
• 6502 Math

• Complete and blog about Lab 1

• 6502 Math Lab

• 6502 Jumps, Branches, and Procedures
• 6502 Math

• Lab 2 - 6502 Math Lab

• Compiler Internals and Compiler Flags

• Executable and Linkable Format
• GCC Documentation - Particularly note the GCC manual for the latest version, and the GCC Internals documentation (link near the bottom of the page)

• Complete and blog about Lab 2

• Edited summary video
• This video does not include the quiz answers or discussion of the blog posts.

• input5.6502 - five-letter-word input routine very similar to the one discussed in the video, used in the Wordle-like game.

• Lab 3 - 6502 Program Lab

• Compiler Optimizations

• Compiler Optimizations
• Link Time Optimization
• Profile-Guided Optimization

• Complete and blog about Lab 3
• Reminder: the first group of blogs is due next week (Oct 6 11:59 PM)