Skip to content

CS 315-02 Lecture/Lab — Meeting Summary (Fall 2025)

  • Date: Sep 02, 2025
  • Time: 02:46 PM Pacific (US and Canada)
  • Meeting ID: 868 6589 0521

Quick Recap

The session covered Project 1 expectations, submission requirements, Makefile usage, code quality, and C programming practices (structs and separate compilation). Greg introduced assembly language fundamentals—registers, instructions, labels, and the contrast with C—and explained repository management, testing prior to submission, and upcoming lab objectives focused on assembly programming and GDB.

Next Steps

Project 1: Requirements and Constraints

  • Include a proper Makefile that builds the required binaries.
  • Implement custom string-to-uint32 conversion (no built-in conversion functions).
  • Implement custom uint32-to-string conversion (do not use printf format specifiers such as %d or %x).
  • Produce output in a fixed order: from low base to high base.
  • Do not use malloc or free; prefer stack-allocated data.
  • Avoid placing logic in main; main should orchestrate function calls only.

Testing and Submission Hygiene

  • Clone the repository into a fresh location and run grading tests before final submission.
  • Ensure the repository contains only source files; do not commit build artifacts.

Code Quality and Structure

  • Maintain consistent formatting, naming (snake_case), and comment styles.
  • Consider separate compilation: place shared helpers in .c files with corresponding .h headers.

Schedule and Communication

  • Attend the lab session tomorrow for GDB setup and assembly exercises.
  • Complete Lab 2 during the lab period tomorrow.
  • Submit Lab 3 by next Monday.
  • Monitor Campus Wire for updates and clarifications.

Summary

Project 1: Expectations and Guidelines

  • Greg outlined modifications to Makefiles, repository cleanliness, and code quality standards.
  • Clarified that base-conversion output must be ordered from lowest base to highest.
  • Explained the rationale for implementing a custom string-to-int conversion (to practice parsing and constraints).
  • Emphasized testing by cloning into a clean directory and running tests before submission.

Separate Compilation in C

  • Organize code into multiple .c files with corresponding .h headers to avoid duplication and improve modularity.
  • Declare function prototypes in headers and include them with "header.h" for local headers.
  • Use Make to manage dependencies between .c and .h files; include headers in rules so changes trigger recompilation.

Code Quality and Style Guidelines

  • Prioritize consistency in formatting, naming (snake_case), and comments.
  • Avoid dynamic memory (malloc/free) for this project; prefer stack allocation.
  • Keep main free of logic; handle errors by calling exit() rather than relying on return codes from main.
  • Stay current via Campus Wire for announcements and clarifications.

Code Quality and Git Practices

  • Keep repositories clean—exclude build outputs and generated files.
  • Follow a sensible Git workflow (e.g., use git rm to remove tracked artifacts; commit with clear messages).
  • Discussed typedef to create aliases for types; noted that typedefs will not be used in this course.

C Structs: Best Practices

  • Favor clarity and explicitness when declaring and using structs.
  • Be cautious with typedefs that obscure pointer types or the nature of variables.
  • Use a consistent pattern: define a single struct type, then initialize, populate, and pass instances across functions as needed.
  • Multiple struct variables are fine; maintain a single struct definition.

Project Submission Files and Editor Themes

  • Required project files: Makefile, numinfo.c, numconv.c.
  • Optional (for separate compilation): numhelpers.c, numhelpers.h.
  • Editor tip (micro): change color themes by editing theme files; a “gruvbox”-style scheme was demonstrated as an example.

Assembly Language: Basics Overview

  • Assembly is a human-readable representation of machine code with simple instructions and no high-level constructs (loops, conditionals).
  • Labels serve as symbolic references for instruction addresses.
  • A simple C program was compared with its assembly equivalent to illustrate control flow and debugging challenges.
  • Debugging tools will be demonstrated in the next lab session.

Assembly Language: Registers Overview

  • Demonstrated storing values in registers and performing operations (e.g., addition).
  • In assembly, functions are private by default; mark them global to expose externally.
  • Introduced symbolic register names and special behavior of register X0 (always 0).
  • Further register conventions will be covered in upcoming lessons.

Assembly Language: Programming Overview

  • Demonstrated assembling and running assembly with GCC.
  • Used underscore naming to avoid collisions between C and assembly function names.
  • Explained C’s startup code (initializes environment, then calls main).
  • Reviewed instruction components (labels, operands, registers).
  • Noted that the target architecture uses 64-bit registers (RISC 5), while typical C int is 32-bit.
  • Provided historical context on evolution from 8-bit to 64-bit systems and prevalence of 64-bit devices.

Upcoming Lab Objectives

  • Set up and use the GDB debugger.
  • Write and run a small assembly program.
  • Understand how assembly informs compiler behavior and program execution.
  • Review provided examples and supplemental materials before and after lab.