AQA A-Level Computer Science (7517)

## Learning Outcomes

- Explain what a **stack frame** is and how it differs from the **call stack**
- Identify the main items typically stored in a stack frame
- Describe what happens to stack frames when a subroutine is called and when it returns
- Explain why stack frames are needed for nested subroutines and recursion
- Trace the call stack through simple pseudocode examples
- Recognise common exam errors, including confusing local variables, parameters, and global variables

## AQA A-Level Computer Science (7517) Syllabus

For the AQA A-Level Computer Science (7517), you are expected to understand the role of stack frames in subroutine calls, with a focus on the following syllabus points:

![Call stack containing separate stack frames for active subroutine calls, each storing a return address, parameters, and local variables.](https://static.pastpaperhero.com/images/aqa-a-level-computer-science-7517-programming-fundamentals-stack-frames_00.png)

_Nested subroutine execution is represented by stacked frames that are pushed on subroutine call and popped on return._

- Know that a **call stack** is a LIFO data structure used to store active subroutine calls
- Identify that a **stack frame** is the block of data for one subroutine call
- Explain that when a subroutine is called, a new stack frame is **pushed** onto the call stack
- Explain that when a subroutine finishes, its stack frame is **popped** from the call stack
- Understand that a stack frame typically stores the **return address**, **parameters/arguments**, and **local variables**
- Explain why each subroutine call needs its own separate data
- Understand how recursion creates multiple stack frames for repeated calls to the same subroutine
- Recognise that too many calls can cause **stack overflow**

## Test Your Knowledge

_Attempt these questions before reading this article. If you find some difficult or cannot remember the answers, look more closely at that area during your revision._

1. What is the difference between a call stack and a stack frame?
2. Name three items typically stored in a stack frame.
3. What happens to the call stack when one subroutine calls another subroutine?
4. Why does recursion require multiple stack frames?
5. How can an error in recursion lead to stack overflow?

## Introduction

When a program runs, it often breaks work into subroutines such as procedures and functions. That makes programs easier to design, test and maintain. However, the processor must still keep track of which subroutine is currently running, what data belongs to it, and where execution should continue afterwards. That is the job of the **call stack** and its **stack frames**.

For AQA, this topic is usually tested in short-definition or explain questions, but it also appears in recursion and trace-style questions. Students often know that "something is stored on a stack" but lose marks by mixing up the whole call stack with one stack frame, or by forgetting the return address.

> **Key Term: stack frame**
> The block of data stored for one subroutine call on the call stack.

### The core idea: call stack and stack frame

A program may have many subroutine calls active at the same time. For example, the main program may call `Sub1`, which then calls `Sub2`, which then calls `Sub3`. The computer needs a way to remember all these unfinished calls in the correct order.

It does this using a **stack**, which is a Last In, First Out structure. The most recent subroutine call is placed on top. That matters because the most recent call must finish before the earlier one can continue.

> **Key Term: call stack**
> A LIFO stack data structure that stores information about active subroutine calls while a program runs.

The two terms are linked, but they are not the same:

- The **call stack** is the whole structure
- A **stack frame** is one item on that structure
- One active subroutine call = one stack frame

A useful way to picture it is as a pile of trays:

- the whole pile is the **call stack**
- each tray is a **stack frame**

If `Main` calls `A`, and `A` calls `B`, the stack grows upward like this:

- Top: frame for `B`
- Under it: frame for `A`
- Bottom: frame for `Main`

When `B` finishes, its frame is removed first. Then `A` continues.

> **Key Term: LIFO**
> Last In, First Out. The item most recently added is the first one removed.

This LIFO order is exactly what subroutine execution needs. The latest call is the one currently running, so it must be the first to finish.

A common mistake is to say "a stack frame stores all subroutines in the program". That is wrong. One stack frame stores data for one call only. If the same function is called three times, there are three separate stack frames.

> **Test Tip:**
> If a question says "define stack frame", do not define the whole stack. Mention that it is the data for a single subroutine call.

### What a stack frame stores and why

AQA-friendly answers should focus on three main items stored in a stack frame:

- return address
- **parameters** or arguments passed into the subroutine
- local variables

> **Key Term: return address**
> The location in the program where execution must continue after a subroutine finishes.

The return address is essential. Suppose the main program reaches line 20 and calls a function. Once that function ends, the processor must know where to go back to. Without the return address, the program would not know which instruction should run next.

Parameters are also stored because each call may receive different input values. For example, if a procedure `PrintSquare(n)` is called with `2`, `5`, and `9` at different times, each call needs its own value of `n`.

> **Key Term: parameter**
> A variable in a subroutine definition that receives a value when the subroutine is called.

Local variables belong only to that subroutine call. They exist while the subroutine runs and are removed when the call ends.

> **Key Term: local variable**
> A variable declared inside a subroutine that can only be accessed within that subroutine call.

This is why local scope is so useful. Each call gets its own private working area. If different calls shared one common set of local variables, one call could overwrite another call's data.

For exam answers, be careful with the difference between **parameters** and **local variables**:

- A **parameter** is input passed into the subroutine
- A **local variable** is created inside the subroutine

Some questions may accept both as data stored in the frame, but they are not the same thing.

Here is a simple example:

```text
PROCEDURE ShowTotal(a, b)
    DECLARE total : INTEGER
    total ← a + b
    OUTPUT total
ENDPROCEDURE
```

For one call to `ShowTotal(4, 7)`, the stack frame would typically include:

- return address
- parameter `a = 4`
- parameter `b = 7`
- local variable `total`

Once the procedure ends, that frame is popped, and `total` stops existing.

This is one reason local variables are usually better than global variables for temporary working values. Their use is limited to the correct subroutine, which reduces unwanted side effects elsewhere in the program.

> **Key Term: scope**
> The part of a program where a variable can be accessed.

Global variables still have some uses, especially when many parts of a program genuinely need the same shared data. But overusing them makes tracing harder because they can be changed from many different places. Stack frames help keep subroutine-specific data separate and controlled.

### Push, pop and tracing subroutine calls

When a subroutine is called, its stack frame is **pushed** onto the top of the call stack. When the subroutine finishes, that frame is **popped** off.

> **Key Term: push**
> To add an item to the top of a stack.
> **Key Term: pop**
> To remove the item from the top of a stack.

That push-pop process is the basic behaviour you need to describe in exam answers.

Consider this pseudocode:

```text
PROCEDURE Main()
    DECLARE x : INTEGER
    x ← 5
    CALL Sub1(x)
    OUTPUT "End of main"
ENDPROCEDURE

PROCEDURE Sub1(a : INTEGER)
    DECLARE b : INTEGER
    b ← a + 2
    CALL Sub2(b)
    OUTPUT "End of Sub1"
ENDPROCEDURE

PROCEDURE Sub2(c : INTEGER)
    DECLARE d : INTEGER
    d ← c * 3
    OUTPUT d
ENDPROCEDURE
```

Let us trace the stack.

First, `Main` is running.

Call stack:

- `Main`

Then `Main` calls `Sub1(x)` with `x = 5`.

Call stack:

- `Sub1` frame: parameter `a = 5`, local variable `b`, return address back to `Main`
- `Main` frame

Then `Sub1` calculates `b = 7` and calls `Sub2(b)`.

Call stack:

- `Sub2` frame: parameter `c = 7`, local variable `d`, return address back to `Sub1`
- `Sub1` frame: `a = 5`, `b = 7`
- `Main` frame

Then `Sub2` calculates `d = 21`, outputs it, and finishes. Its frame is popped.

Call stack:

- `Sub1` frame
- `Main` frame

Then `Sub1` continues after the call to `Sub2`, outputs `"End of Sub1"`, and finishes. Its frame is popped.

Call stack:

- `Main` frame

Then `Main` continues, outputs `"End of main"`, and finishes.

The most important point is that the return address lets each subroutine continue at the correct place after the called subroutine ends. `Sub1` does not restart from the beginning after `Sub2` finishes. It resumes from the instruction after the call.

> **Test Tip:**
> In a "describe what happens" question, use the verbs **pushed**, **popped**, **stored**, and **returned**. These usually match the mark scheme well.

Students sometimes say that when `Sub2` ends, control returns to the start of `Sub1`. That is inaccurate. It returns to the next instruction after the call because that position was stored as the return address.

### Recursion, separate frames and stack overflow

Recursion is where a subroutine calls itself. Stack frames are especially important here because the same subroutine may be active many times at once.

> **Key Term: recursion**
> A programming technique in which a subroutine calls itself.

Consider this function:

```text
FUNCTION Factorial(n : INTEGER) RETURNS INTEGER
    IF n = 1 THEN
        RETURN 1
    ELSE
        RETURN n * Factorial(n - 1)
    ENDIF
ENDFUNCTION
```

If the program calls `Factorial(4)`, the calls happen like this:

- `Factorial(4)` calls `Factorial(3)`
- `Factorial(3)` calls `Factorial(2)`
- `Factorial(2)` calls `Factorial(1)`

At the deepest point, there are four active calls, so there are four separate stack frames.

Call stack from top to bottom:

- `Factorial(1)`
- `Factorial(2)`
- `Factorial(3)`
- `Factorial(4)`

Each frame has its own value of `n` and its own return address. This is the key idea that many students miss. Even though the function name is the same each time, the calls do not share one variable `n`. Each call gets its own separate copy in its own frame.

Now the base case is reached at `n = 1`, so the stack starts to unwind:

1. `Factorial(1)` returns `1`, so its frame is popped
2. `Factorial(2)` returns `2 × 1 = 2`, so its frame is popped
3. `Factorial(3)` returns `3 × 2 = 6`, so its frame is popped
4. `Factorial(4)` returns `4 × 6 = 24`, so its frame is popped

Worked result:

- `Factorial(1) = 1`
- `Factorial(2) = 2`
- `Factorial(3) = 6`
- `Factorial(4) = 24`

This shows why stack frames are necessary for recursion:

- each call must keep its own parameter values separate
- each call must remember where to return to
- calls must finish in reverse order

Without stack frames, recursive calls would overwrite each other's data.

A related exam point is **stack overflow**.

> **Key Term: stack overflow**
> An error that occurs when too many stack frames are pushed onto the call stack and it runs out of space.

This usually happens when recursion goes too deep, often because there is no correct base case. For example:

```text
FUNCTION Broken(n : INTEGER) RETURNS INTEGER
    RETURN Broken(n - 1)
ENDFUNCTION
```

This never stops. New frames keep being pushed until memory allocated to the stack is exhausted.

Do not confuse stack overflow with heap problems. For this topic, the issue is too many frames on the **call stack**, not failure of heap allocation.

The same push-pop idea also explains how a system can pause one task to deal with an interrupt or exception and then continue. The current state is stored, the new code runs, and then the earlier state can be restored. For your exam, though, the safest focus is still subroutine calls, return addresses, parameters and local variables.

## Key Point Checklist

_This article has covered the following key knowledge points:_

- A call stack is a LIFO data structure used to store active subroutine calls
- A stack frame is one block of data for one subroutine call
- When a subroutine is called, a new stack frame is pushed onto the call stack
- When a subroutine finishes, its frame is popped from the call stack
- Typical stack frame contents are the return address, parameters, and local variables
- The return address tells the processor where execution should continue after the subroutine ends
- Parameters are values passed into a subroutine, while local variables are declared inside it
- Each subroutine call gets its own separate stack frame
- This separation is especially important in nested calls and recursion
- Recursive calls to the same subroutine do not share one set of local variables
- If too many calls are made, the stack can run out of space and cause stack overflow
- A common exam mistake is confusing the whole call stack with one stack frame

## Key Terms and Concepts

- stack frame
- call stack
- LIFO
- return address
- parameter
- local variable
- scope
- push
- pop
- recursion
- stack overflow


Programming Fundamentals - Stack frames