# Befunge

Befunge is a two-dimensional stack-based, reflective, esoteric programming language. It differs from conventional languages in that programs are arranged on a two-dimensional grid. "Arrow" instructions direct the control flow to the left, right, up or down, and loops are constructed by sending the control flow in a cycle. It has been described as "a cross between Forth and Lemmings".
Befunge was created by Chris Pressey in 1993 for the Amiga. The language was designed to be as hard to compile as possible, featuring self-modifying code and a multi-dimensional playfield. Despite this, several compilers have been written for the language. The original Befunge-93 specification limited programs to an 80x25 grid, and while not Turing-complete, subsequent extensions like Funge-98 expanded the concept to achieve Turing completeness.
The name "Befunge" originated from a typing error in an online discussion. While it was designed to be difficult to compile, compilers such as bef2c and Betty have managed to implement the language using various techniques. Befunge programs are characterized by their use of arrows to change control flow, and they can produce outputs like random number sequences or classic "Hello, World!" messages.

## History

The language was originally created by Chris Pressey in 1993 for the Amiga, as an attempt to devise a language which is as hard to compile as possible. Note that the p command allows for self-modifying code. Nevertheless, a number of compilers have subsequently been written. A number of extensions to the original "Befunge-93" specification also exist, most notably Funge-98, which extends the concept to an arbitrary number of dimensions and can be multithreaded, with multiple instruction pointers operating simultaneously on the same space. Befunge-extensions and variants are called Fungeoids or just Funges.
The Befunge-93 specification restricts each valid program to a grid of 80 instructions horizontally by 25 instructions vertically. Program execution which exceeds these limits "wraps around" to a corresponding point on the other side of the grid; a Befunge program is in this manner topologically equivalent to a torus. Since a Befunge-93 program can only have a single stack and its storage array is bounded, the Befunge-93 language is not Turing-complete (however, it has been shown that Befunge-93 is Turing Complete with unbounded stack word size). The later Funge-98 specification provides Turing completeness by removing the size restrictions on the program; rather than wrapping around at a fixed limit, the movement of a Funge-98 instruction pointer follows a model dubbed "Lahey-space" after its originator, Chris Lahey. In this model, the grid behaves like a torus of finite size with respect to wrapping, while still allowing itself to be extended indefinitely.

## Etymology

The word Befunge is derived from a typing error in an online discussion, where the word 'before' was intended.

## Compilation

As stated, the design goal for Befunge was to create a language which was difficult to compile. This was attempted with the implementation of self-modifying code (the 'p' instruction can write new instructions into the playfield) and a multi-dimensional playfield (the same instruction can be executed in four different directions).
Nevertheless, these obstacles have been overcome, to some degree, and Befunge compilers have been written using appropriate techniques.
The bef2c compiler included with the standard Befunge-93 distribution uses threaded code: each instruction is compiled to a snippet of C code, and control flows through the snippets just as it does in a Befunge interpreter (that is, conditionally on the value of some 'direction' register). This does not result in a significant advantage over a good interpreter. Note that the bef2c compiler is not correct since it does not handle either 'p' or string mode, but it would not be impossible to make it do so (although the C language might not be well-suited for this).
The etty compiler, for example, treats every possible straight line of instructions as a subprogram, and if a 'p' instruction alters that subprogram, that subprogram is recompiled. This variation on just-in-time compilation results in a much better advantage over an interpreter, since many instructions can be executed in native code without making intervening decisions on the 'direction' register.

## Sample Befunge-93 code

The technique of using arrows to change control flow is demonstrated in the random number generator program below. The Befunge instruction pointer begins in the upper left corner and will travel to the right if not redirected. Following the arrows around, the ? instructions send the instruction pointer in random cardinal directions until the pointer hits a digit, pushing it to the stack. Then the arrows navigate to the . to output the digit from the stack and return the pointer to the first directional randomiser. There is no @ to terminate this program, so it produces an endless stream of random numbers from 1 to 9.
The following code is an example of the classic "Hello World!" program. First the letters "olleH" are pushed onto the stack as ASCII numbers. These are then popped from the stack in LIFO order and output as text characters to give "Hello". A space is character number 32 in ASCII, which here is constructed by multiplying 4 and 8, before being output as text. The remaining code then outputs "World!" in a similar way, followed by ASCII character 10 (a line feed character, moving the output cursor to a new line).
The following code is a slightly more complicated version. It adds the ASCII character 10 (a line feed character) to the stack, and then pushes "!dlrow ,olleH" to the stack. Again, LIFO ordering means that "H" is now the top of the stack and will be the first printed, "e" is second, and so on. To print the characters, the program enters a loop that first duplicates the top value on the stack (so now the stack would look like "\n!dlrow ,olleHH"). Then the "_" operation will pop the duplicated value, and go right if it's a zero, left otherwise. (This assumes a compliant interpreter that "returns" 0 when popping an empty stack.) When it goes left, it pops and prints the top value as an ASCII character. It then duplicates the next character and loops back to the "_" test, continuing to print the rest of the stack until it is empty and so the next value popped is 0, at which point "@" ends the program.

## Befunge-93 instruction list

| 0-9 | Push this number onto the stack. |
| + | Addition: Pop a and b, then push a+b |
| - | Subtraction: Pop a and b, then push b-a |
| * | Multiplication: Pop a and b, then push a*b |
| / | Integer division: Pop a and b, then push b/a, rounded towards 0. |
| % | Modulo: Pop a and b, then push the remainder of the integer division of b/a. |
| ! | Logical NOT: Pop a value. If the value is zero, push 1; otherwise, push zero. |
| ` | Greater than: Pop a and b, then push 1 if b>a, otherwise zero. |
| > | Start moving right |
| < | Start moving left |
| ^ | Start moving up |
| v | Start moving down |
| ? | Start moving in a random cardinal direction |
| _ | Pop a value; move right if value=0, left otherwise |
| | | Pop a value; move down if value=0, up otherwise |
| " | Start string mode: push each character's ASCII value all the way up to the next " |
| : | Duplicate value on top of the stack |
| \ | Swap two values on top of the stack |
| $ | Pop value from the stack and discard it |
| . | Pop value and output as an integer followed by a space |
| , | Pop value and output as ASCII character |
| # | Bridge: Skip next cell |
| p | A "put" call (a way to store a value for later use). Pop y, x, and v, then change the character at (x,y) in the program to the character with ASCII value v |
| g | A "get" call (a way to retrieve data in storage). Pop y and x, then push ASCII value of the character at that position in the program |
| & | Ask user for a number and push it |
| ~ | Ask user for a character and push its ASCII value |
| @ | End program |
| (space) | No-op. Does nothing |
Most one-dimensional programming languages require some syntactic distinction between comment text and source code — although that distinction may be as trivial as Brainfuck's rule that any character not in the set +-<>,. is a comment. Languages like Lisp and Python treat strings as comments in contexts where the values are not used. Similarly, in Befunge, there is no comment syntax: to embed documentation in the code, the programmer simply routes the control flow around the "comment" area, so that the text in that area is never executed.