How Hardware Supports Function Calls and Character Data

Calling a function seems simple in high-level code, but at the hardware level it requires a careful protocol for saving return addresses, passing arguments, and preserving register values. This article explains how procedure calls are implemented using dedicated registers and a stack, then covers how processors represent human-readable text as sequences of encoded characters.

Procedure CallsStack MemoryCharacter Encoding

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱۵ شهریور ۱۴۰۵

What Happens When a Function Is Called

Calling a Procedure (a function or subroutine) requires more than just jumping to its code. The processor must remember where to return afterward, pass input arguments, receive a result, and make sure the calling code's register values are not silently overwritten by the called procedure. RISC-V handles this through a defined convention rather than special hardware magic.

The Jump-and-Link Instruction

RISC-V provides a dedicated instruction for calling procedures that automatically saves the return location:

jal ra, ProcedureAddress

This instruction jumps execution to ProcedureAddress while simultaneously storing the address of the next instruction into a designated register, conventionally called ra (return address). When the procedure finishes, it uses this saved address to jump back:

jalr x0, 0(ra)

This returns control to exactly the instruction that follows the original call.

Register Conventions for Passing Data

To keep procedure calls predictable across different compilers and programs, RISC-V follows a fixed Register Convention:

  • A specific range of registers is reserved for passing Argument Values into a procedure.
  • A specific register is reserved for returning the Result Value back to the caller.
  • Some registers are designated as Saved Registers, which a called procedure must preserve and restore before returning if it intends to use them.
  • Other registers are Temporary Registers, which a called procedure is free to overwrite without any obligation to restore their original value.

The Stack: Handling Nested and Recursive Calls

A single set of registers is not enough when procedures call other procedures, or call themselves recursively. To handle this, RISC-V uses a region of memory called the Stack, managed through a dedicated Stack Pointer register.

Before a procedure overwrites a saved register it needs to reuse, it pushes that register's current value onto the stack; before returning, it restores the value by popping it back:

Reserve stack space:
addi sp, sp, -8

Save a register's value:
sd s0, 0(sp)

Restore it later:
ld s0, 0(sp)

Release stack space:
addi sp, sp, 8

This mechanism allows an arbitrary depth of nested or recursive calls, since each call gets its own private area of stack memory for anything it needs to preserve.

Representing Text: Characters and Encoding

Beyond numbers, computers also need to represent human-readable text. Each individual character is stored using a numeric encoding standard, most commonly ASCII for basic Latin text or Unicode for a much broader range of scripts and symbols.

A sequence of characters forming text is called a String, and it is typically stored in memory as consecutive bytes, one per character, often ending with a special terminating value that marks where the string ends.

Why These Conventions Matter

Because register usage and stack management follow a strict, agreed-upon convention rather than being decided ad hoc by each program, code compiled by different compilers, or written in different languages, can call procedures written by each other correctly and safely — a property essential for building large software systems out of independently developed components.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Common Misconceptions About Parallel Computing and the Book's Final Lessons

After covering everything from thread-level parallelism to warehouse-scale computing, it is worth correcting persistent misconceptions about parallel systems that even experienced engineers sometimes hold. This article addresses common fallacies about scaling and parallel hardware, then closes out the parallel processing chapter by tying together the full journey from a single instruction to a building full of cooperating machines.

ادامه

Real Stuff: Benchmarking CPUs Against GPUs and Multiprocessor Matrix Multiply

Comparing a CPU and a GPU fairly requires a model that accounts for both computational throughput and memory bandwidth limits together. This article introduces the roofline model used to compare real hardware like the Intel Core i7 and NVIDIA Tesla GPU, then shows how matrix multiplication is accelerated across multiple processors as the final practical application of this chapter's parallel concepts.

ادامه

Benchmarking Multiprocessors and Modeling Parallel Performance

Measuring the performance of a parallel system requires different tools and metrics than measuring a single-core processor. This article covers the specialized benchmarks used to evaluate multiprocessor systems, explains how to model scaling behavior as more processors are added, and revisits Amdahl's Law in the context of real-world performance measurement.

ادامه

Cluster Networking: Connecting to the World Outside

A cluster of machines is only useful if it can communicate efficiently both internally and with the outside world. This article covers the networking layers involved in cluster communication, the tradeoffs between latency and bandwidth at scale, and how clusters connect to external networks and users.

ادامه

Clusters, Warehouse-Scale Computers, and Network Topologies

Beyond a single chip, parallelism extends to entire buildings full of independent computers working together. This article explains the shift from shared memory multiprocessing to clusters of separate machines, introduces the concept of warehouse-scale computing, and covers the network topologies that connect these independent machines efficiently.

ادامه

An Introduction to GPUs: Massive Parallelism for Data-Heavy Workloads

A GPU takes the SIMD idea covered earlier in this series to an extreme scale, running thousands of lightweight threads simultaneously to process massive amounts of independent data. This article explains why GPUs are architecturally so different from CPUs, how their thread execution model works, and what kinds of workloads benefit most from this design.

ادامه