Why trace on paper
Reading Befunge like prose does not work, because the order of the characters on the page is not the order of execution. The surest way to understand a program is to act as the interpreter yourself: move the pointer one cell at a time, apply the instruction, and record what changed. This is slow for large programs but extremely effective for small ones, and it is the best way to learn what each command does.
The method needs only a pencil and a table.
The table
Make a table with one row per step and these columns:
- Step number
- Position of the pointer, as column and row
- Character in that cell
- Direction the pointer is moving after the instruction
- Stack contents after the instruction, with the top on the right
- Output so far
Each step does exactly one thing: execute the cell the pointer is on, then move one cell. Writing the stack after each step is the part that catches most errors, so do not skip it.
A worked example
Consider this one-row program:
34*2-.@The pointer starts at column 0, row 0, moving right.
| Step | Position | Cell | Direction | Stack (top at right) | Output |
|---|---|---|---|---|---|
| 1 | (0, 0) | 3 | right | 3 | |
| 2 | (1, 0) | 4 | right | 3 4 | |
| 3 | (2, 0) | * | right | 12 | |
| 4 | (3, 0) | 2 | right | 12 2 | |
| 5 | (4, 0) | - | right | 10 | |
| 6 | (5, 0) | . | right | (empty) | 10 |
| 7 | (6, 0) | @ | stop | (empty) | 10 |
Check the arithmetic: 3 times 4 is 12; 12 minus 2 is 10. At step 5, the subtraction pops 2 first (the top), then 12, and computes 12 minus 2. The dot prints 10 followed by a space, then the program ends.
Had the program been 2 followed by 34* and then -, the result would be 2 minus 12, which is negative 10. The table makes such ordering differences visible.
Tracing a turn
A row with no turns is easy. The real value of tracing is when the pointer changes direction. Here is a short program on two rows:
2v
>.@Step by step: the pointer begins at (0, 0) and runs 2, so the stack is 2. At (1, 0) it meets v, so the direction becomes down, and it moves to (1, 1). That cell holds >, which turns it right, and it moves to (2, 1). There . prints 2. Then @ ends the program at (3, 1).
Note that the cell at (0, 1) is a space, and the pointer never visits it. A table lets you see what is skipped, and cells that are never visited are an example of dead code.
Tracing a decision
With a decision command such as _, the table needs one extra thought: what value was popped and which way did that send the pointer? Write that in the direction column, for example “popped 0, so right”. Doing this explicitly prevents the common mix-up between zero and nonzero.
Handling loops
A loop revisits the same cells many times, so the table grows quickly. Two tricks keep it manageable.
First, trace the first full pass through the loop in detail, then the second, and see whether the stack change per pass is regular. If each pass removes one value and prints it, you can summarize the rest as “repeats until the stack is empty”.
Second, use a tiny input. Test with a short string or a small counter, so you can complete the whole trace. If you are curious about structures like these, the topic of Befunge loops goes into them in depth.
Tips for accuracy
- Move the pointer first in your head, then write down the new position, never the other way around.
- Remember wrap-around: leaving the right edge brings the pointer to column 0 of the same row.
- In string mode, record each pushed character as its numeric code, or as the letter in quotes, but be consistent.
- Mark when a skip instruction jumps a cell, since the skipped cell is not run.
- Double-check each arithmetic step before moving on.
When tracing by hand is not enough
For larger programs, tracing on paper becomes tedious, and software can do the same job faster. A simple trace visualizer shows the same columns automatically, and building one is a good project once you understand how the pointer and stack work. Until then, the pencil method has an advantage: it forces you to understand every step, which is what makes the next program easier to write.
Make a habit of tracing your own programs before running them. If your prediction and the actual result differ, the table usually shows you exactly where your picture of the program went wrong.