Vector table structure in ARM Architecture - Time & Space Complexity
We want to understand how the time to access an interrupt handler grows as the number of interrupts increases in a vector table.
How does the structure of the vector table affect the speed of finding the right handler?
Analyze the time complexity of the following vector table lookup code.
LDR R0, =VectorTable ; Load base address of vector table
LDR R1, [R0, R2, LSL #2] ; Load handler address using interrupt number in R2
BX R1 ; Branch to handler
This code loads the address of the interrupt handler directly from the vector table using the interrupt number as an index.
In this code, there is no loop or recursion.
- Primary operation: Single memory load using the interrupt number as index.
- How many times: Exactly once per interrupt.
The time to find the handler does not increase as the number of interrupts grows.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 1 memory load |
| 100 | 1 memory load |
| 1000 | 1 memory load |
Pattern observation: The operation count stays the same no matter how many interrupts there are.
Time Complexity: O(1)
This means the time to find the interrupt handler is constant and does not depend on the number of interrupts.
[X] Wrong: "Finding the interrupt handler takes longer if there are more interrupts in the vector table."
[OK] Correct: The vector table uses direct indexing, so the handler address is found immediately without searching through entries.
Understanding how direct indexing in a vector table leads to constant time access is a useful skill for embedded systems and low-level programming roles.
"What if the vector table was implemented as a linked list instead of an array? How would the time complexity change?"
Practice
Solution
Step 1: Understand vector table structure
The ARM vector table begins with the initial stack pointer value to set up the stack.Step 2: Identify the first entry
The first entry is the initial stack pointer address, followed by the reset handler address.Final Answer:
Initial stack pointer address -> Option CQuick Check:
First entry = Initial stack pointer address [OK]
- Confusing reset handler as first entry
- Thinking program counter is first
- Assuming interrupt routine is first
Solution
Step 1: Recall vector table order
The first entry is the initial stack pointer, so the second entry is the reset handler.Step 2: Confirm second entry role
The reset handler is the address where the processor starts executing after reset.Final Answer:
Reset handler address -> Option AQuick Check:
Second entry = Reset handler address [OK]
- Mixing up with interrupt handlers
- Choosing stack pointer again
- Confusing with exception handlers
0x00000000: 0x20001000 (Initial SP)
0x00000004: 0x00001005 (Reset Handler)
0x00000008: 0x00001010 (NMI Handler)
0x0000000C: 0x00001020 (HardFault Handler)
Which address will the processor jump to on a HardFault exception?
Solution
Step 1: Locate HardFault entry in vector table
The HardFault handler address is at offset 0x0C in the vector table.Step 2: Identify the address at 0x0000000C
The address at 0x0000000C is 0x00001020, which is the HardFault handler.Final Answer:
0x00001020 -> Option DQuick Check:
HardFault handler = 0x00001020 [OK]
- Choosing reset handler address
- Confusing NMI and HardFault handlers
- Selecting initial stack pointer
Solution
Step 1: Understand role of first vector entry
The first entry sets the initial stack pointer address for the processor.Step 2: Analyze effect of setting it to zero
Setting it to 0x00000000 means the stack pointer points to an invalid memory location, causing a crash.Final Answer:
Stack pointer will be invalid causing a crash -> Option AQuick Check:
Invalid stack pointer = Crash [OK]
- Thinking reset handler won't run
- Assuming interrupts are disabled
- Believing processor resets normally
Solution
Step 1: Understand vector table layout
The vector table has fixed slots for each exception and interrupt type.Step 2: Identify correct slot for custom interrupt
Custom peripheral interrupts must be placed at their assigned interrupt vector slot, not at stack pointer or reset handler entries.Final Answer:
At the specific interrupt vector slot assigned to that peripheral -> Option BQuick Check:
Custom handler = Assigned interrupt vector slot [OK]
- Replacing stack pointer or reset handler
- Appending handler at vector table end
- Ignoring fixed vector slot assignments
Ready to prove it?
Pass the test and this pattern moves unknown
