Subroutines

Part of Programming Fundamentals

Reusable named code blocks that reduce repetition and structure programs.

Why This Matters

Every non-trivial program repeats logic. Without subroutines, a programmer copying the same ten instructions twenty times creates twenty opportunities for inconsistency and a maintenance nightmare. Subroutines — also called functions, procedures, or routines depending on language and era — collapse repetition into a single named unit. Call it once, call it a thousand times; the logic lives in one place.

For a civilization rebuilding computing from scratch, subroutines are the first major abstraction above raw instruction sequences. They make programs readable, testable in isolation, and maintainable by multiple people. A library of proven subroutines becomes a foundation that future programmers build on rather than reinvent.

The concept is also hardware-supported: most processors have dedicated CALL and RETURN instructions that manage the mechanics of subroutine invocation efficiently. Understanding subroutines means understanding how those instructions interact with the stack — a foundational skill for anyone writing assembly or understanding how compiled code works.

The Call-Return Mechanism

When a processor executes a CALL instruction, two things happen: the address of the next instruction (the return address) is saved, and execution jumps to the subroutine’s first instruction. When the subroutine finishes, a RETURN instruction retrieves the saved address and jumps back to where execution left off.

Early systems saved the return address in a fixed memory location — a single dedicated cell per subroutine. This works for non-nested calls but fails immediately if subroutine A calls subroutine B: B’s call would overwrite A’s return address. The solution is the stack.

A stack is a last-in-first-out region of memory. The processor maintains a stack pointer register pointing to the current top. CALL pushes the return address onto the stack (writes it, advances the pointer); RETURN pops it (reads it, retreats the pointer). Because LIFO order matches call nesting — the most recently called subroutine always returns first — the stack handles arbitrary call depth correctly.

On a simple 8-bit or 16-bit processor you can implement this manually if CALL/RETURN are not available: save the program counter to a memory address before jumping, restore it before returning. Understanding the mechanism at this level prepares you to debug stack corruption and understand recursion limits.

Parameters and Return Values

A subroutine that always operates on the same data is limited. Parameters allow callers to pass different data each time. Return values let the subroutine report results back.

Three common conventions exist for passing parameters:

Registers: Fast, limited. Before calling, load arguments into specific registers (e.g., register A = first parameter, register B = second). The subroutine reads those registers. Simple processors with few registers use this method. Works well for one or two parameters.

Stack: Scalable. Before calling, push parameters onto the stack. The subroutine reads them by indexing relative to the stack pointer. After return, the caller cleans up by adjusting the stack pointer. This convention scales to many parameters and enables reentrant code.

Memory (fixed buffer): Pass the address of a memory region containing parameters. The subroutine reads from and writes to that region. Simple to implement but not reentrant — concurrent calls would corrupt shared memory.

Return values follow similar conventions. A single integer result typically goes in a dedicated register (register A or register pair HL are common choices). Multiple values or large structures go through a memory address passed as a parameter.

Documenting the calling convention for every subroutine is critical. If caller and callee disagree about which register holds the first argument, the program fails silently with corrupted data rather than an obvious error.

The Stack Frame

When parameters, return addresses, and local variables all live on the stack, they form a structured region called a stack frame (or activation record). Each subroutine call creates a new frame; return destroys it.

A typical frame layout (growing downward):

[return address]    ← pushed by CALL
[saved frame ptr]   ← pushed by subroutine prologue
[local variables]   ← allocated by subroutine
[parameters]        ← pushed by caller before CALL

The frame pointer (FP or BP register) points to a fixed position within the frame. Local variables are at FP-offset; parameters are at FP+offset. This is stable even as the stack pointer moves during the subroutine’s execution.

In assembly, the subroutine prologue and epilogue manage the frame:

; Prologue
PUSH FP         ; save caller's frame pointer
MOV FP, SP      ; establish new frame pointer
SUB SP, N       ; reserve N bytes for locals

; ... subroutine body ...

; Epilogue
MOV SP, FP      ; release locals
POP FP          ; restore caller's frame pointer
RET             ; return to caller

Understanding the stack frame is essential for debugging: a stack trace is simply the chain of active frames. When a program crashes, reading the stack reveals every active subroutine call and the state at each level.

Recursion

A subroutine that calls itself is recursive. Because each call creates a new stack frame with its own local variables and return address, recursion works correctly as long as it terminates — each call must eventually reach a base case that returns without calling again.

Classic recursive example: factorial.

; factorial(n): returns n! in register A
; Base case: n=0 → return 1
; Recursive case: return n * factorial(n-1)

factorial:
    CMP A, 0
    JNE recurse
    MOV A, 1
    RET
recurse:
    PUSH A          ; save n
    SUB A, 1
    CALL factorial  ; A = factorial(n-1)
    POP B           ; restore n into B
    MUL A, B        ; A = n * factorial(n-1)
    RET

Each call pushes n and a return address. The stack grows one frame per level. For factorial(10), ten frames exist simultaneously. Stack depth is finite — exceeding it causes a stack overflow. Designing recursive algorithms requires knowing the maximum call depth and ensuring the stack is large enough.

Iteration can always replace recursion. For resource-constrained systems, prefer iteration. Recursion is valuable for clarity when processing tree-structured data (directory trees, expression parsers) where the natural structure matches the recursive call pattern.

Building a Subroutine Library

A subroutine library is a collection of tested, documented routines that other programs use. For an early computing system, a useful baseline library includes:

String operations: copy string to buffer, compare two strings, find substring, convert integer to decimal string, parse decimal string to integer.

Math routines: multiply two integers (for processors without MUL instruction), divide, compute remainder, find maximum/minimum of two values.

I/O primitives: print character to output device, read character from input, print null-terminated string, print integer in decimal.

Memory utilities: fill memory region with byte value, copy memory region, compare two regions.

Each routine needs a comment block documenting: purpose, parameters (register or stack), return value, registers modified (so callers know what to save), and any edge cases (empty string, division by zero).

Testing subroutines in isolation before using them in larger programs saves enormous debugging time. Write a small test program that calls the subroutine with known inputs and verifies the output matches expectation. Fix the subroutine once; benefit everywhere it is called.

A physical card file or logbook documenting every library routine — name, location in ROM or object file, parameter conventions, behavior — is an invaluable reference as the library grows beyond what memory can hold.