← All projects

Project case study

x86 assembly & C integration

Six labs exploring the interface between C programs, assembly routines, registers, and the stack.

Contribution / contextCoursework · Assembly routines and C drivers
Tools & conceptsx86 assembly · C · Stack frames · Recursion
Available evidenceAssembly source and C driver programs

The problem

A function call looks simple in C, but its implementation depends on registers, memory, argument passing, and return values. This lab series works through those mechanisms explicitly in x86 assembly.

The sequence progresses from basic build and debug workflows to addressing modes, control flow, stack frames, and recursive function calls.

From C calls to stack frames

Fibonacci and factorial

The later labs provide concrete examples of recursion. Lab 5 contains a Fibonacci routine, while Lab 6 contains a factorial routine with a C driver. These examples make the relationship between call frames, saved state, and return values inspectable in source.

LabFocusSource
01Build and debugLab 1 assembly
02Registers and dataLab 2 assembly
03Flags and control flowLab 3 assembly
04Addressing modesLab 4 assembly
05Stack frames and FibonacciLab 5 assembly
06Function interfaces and factorialLab 6 assembly

Small programs expose the interface

The C drivers show how the routines are called. Keeping the caller and assembly implementation together helps connect the function interface to argument handling and the return path.

Evidence & verification

The repository contains assembly implementations and C drivers. The drivers provide an intended way to exercise the routines; their presence alone does not establish that all inputs pass.

No automated regression suite or recorded test results are included in the public repository. A useful validation extension would compare the assembly routines with a C reference for base cases, representative values, and inputs near the chosen integer range.

What would strengthen the project

A reproducible toolchain guide and a small noninteractive test driver would turn these coursework artifacts into a clearer demonstration. Debugger captures could illustrate the stack at each recursive call and show how the return value propagates back to C.

Inspect the work