Brainfuck

From Wikipedia, the free encyclopedia
Jump to: navigation, search
To be distinguished from Brain Fuck Scheduler.
Brainfuck
Paradigm(s) esoteric, imperative, structured
Designed by Urban Müller
Appeared in 1993
Typing discipline static, strong, manifest
Influenced by P′′, FALSE
Filename extension(s) .b, .bf

Brainfuck is an esoteric programming language noted for its extreme minimalism. The language consists of only eight simple commands and an instruction pointer. It is designed to challenge and amuse programmers, and was not made to be suitable for practical use. It was created in 1993 by Urban Müller.

Language design[edit]

Urban Müller created brainfuck in 1993 with the intention of designing a language which could be implemented with the smallest possible compiler,[1] inspired by the 1024-byte compiler for the FALSE programming language.[2] Several brainfuck compilers have been made smaller than 200 bytes. One compiler of 100 bytes is known to exist.[3] The classic distribution is Müller's version 2, containing a compiler for the Amiga, an interpreter, example programs, and a readme document.[4]

The language consists of eight commands, listed below. A brainfuck program is a sequence of these commands, possibly interspersed with other characters (which are ignored). The commands are executed sequentially, with some exceptions: an instruction pointer begins at the first command, and each command it points to is executed, after which it normally moves forward to the next command. The program terminates when the instruction pointer moves past the last command.

The brainfuck language uses a simple machine model consisting of the program and instruction pointer, as well as an array of at least 30,000 byte cells initialized to zero; a movable data pointer (initialized to point to the leftmost byte of the array); and two streams of bytes for input and output (most often connected to a keyboard and a monitor respectively, and using the ASCII character encoding).

Commands[edit]

The eight language commands, each consisting of a single character:

Character Meaning
> increment the data pointer (to point to the next cell to the right).
< decrement the data pointer (to point to the next cell to the left).
+ increment (increase by one) the byte at the data pointer.
- decrement (decrease by one) the byte at the data pointer.
. output the byte at the data pointer.
, accept one byte of input, storing its value in the byte at the data pointer.
[ if the byte at the data pointer is zero, then instead of moving the instruction pointer forward to the next command, jump it forward to the command after the matching ] command.
] if the byte at the data pointer is nonzero, then instead of moving the instruction pointer forward to the next command, jump it back to the command after the matching [ command.

(Alternatively, the ] command may instead be translated as an unconditional jump to the corresponding [ command, or vice versa; programs will behave the same but will run more slowly, due to unnecessary double searching.)

[ and ] match as parentheses usually do: each [ matches exactly one ] and vice versa, the [ comes first, and there can be no unmatched [ or ] between the two.

Brainfuck programs can be translated into C using the following substitutions, assuming ptr is of type unsigned char* and has been initialized to point to an array of zeroed bytes:

brainfuck command C equivalent
(Program Start) char array[infinitely large size];
char *ptr=array;
> ++ptr;
< --ptr;
+ ++*ptr;
- --*ptr;
. putchar(*ptr);
, *ptr=getchar();
[ while (*ptr) {
] }

As the name suggests, brainfuck programs tend to be difficult to comprehend. This is partly because any mildly complex task requires a long sequence of commands; partly it is because the program's text gives no direct indications of the program's state. These, as well as brainfuck's inefficiency and its limited input/output capabilities, are some of the reasons it is not used for serious programming. Nonetheless, like any Turing-complete language, brainfuck is theoretically capable of computing any computable function or simulating any other computational model, if given access to an unlimited amount of memory.[5] A variety of brainfuck programs have been written.[6] Although brainfuck programs, especially complicated ones, are difficult to write, it is quite trivial to write an interpreter for brainfuck in a more typical language such as C due to its simplicity. There even exists a brainfuck interpreter written in the brainfuck language itself.[7]

Brainfuck's formal "parent language"[edit]

Except for its two I/O commands, brainfuck is a minor variation of the formal programming language P′′ created by Corrado Böhm in 1964. In fact, using six symbols equivalent to the respective brainfuck commands +, -, <, >, [, ], Böhm provided an explicit program for each of the basic functions that together serve to compute any computable function. So in a very real sense, the first "brainfuck" programs appear in Böhm's 1964 paper – and they were programs sufficient to prove Turing-completeness.

Examples[edit]

Hello World![edit]

The following program prints "Hello World!" and a newline to the screen:

  1. +++++ +++               Set Cell #0 to 8
    
  2. [
    
  3.     >++++               Add 4 to Cell #1; this will always set Cell #1 to 4
    
  4.     [                   as the cell will be cleared by the loop
    
  5.         >++             Add 2 to Cell #2
    
  6.         >+++            Add 3 to Cell #3
    
  7.         >+++            Add 3 to Cell #4
    
  8.         >+              Add 1 to Cell #5
    
  9.         <<<<-           Decrement the loop counter in Cell #1
    
  10.     ]                   Loop till Cell #1 is zero; number of iterations is 4
    
  11.     >+                  Add 1 to Cell #2
    
  12.     >+                  Add 1 to Cell #3
    
  13.     >-                  Subtract 1 from Cell #4
    
  14.     >>+                 Add 1 to Cell #6
    
  15.     [<]                 Move back to the first zero cell you find; this will
    
  16.                         be Cell #1 which was cleared by the previous loop
    
  17.     <-                  Decrement the loop Counter in Cell #0
    
  18. ]                       Loop till Cell #0 is zero; number of iterations is 8
    
  19.  
    
  20. The result of this is:
    
  21. Cell No :   0   1   2   3   4   5   6
    
  22. Contents:   0   0  72 104  88  32   8
    
  23. Pointer :   ^
    
  24.  
    
  25. >>.                     Cell #2 has value 72 which is 'H'
    
  26. >---.                   Subtract 3 from Cell #3 to get 101 which is 'e'
    
  27. +++++ ++..+++.          Likewise for 'llo' from Cell #3
    
  28. >>.                     Cell #5 is 32 for the space
    
  29. <-.                     Subtract 1 from Cell #4 for 87 to give a 'W'
    
  30. <.                      Cell #3 was set to 'o' from the end of 'Hello'
    
  31. +++.----- -.----- ---.  Cell #3 for 'rl' and 'd'
    
  32. >>+.                    Add 1 to Cell #5 gives us an exclamation point
    
  33. >++.                    And finally a newline from Cell #6
    

For readability, this code has been spread across many lines and blanks and comments have been added. Brainfuck ignores all characters except the eight commands +-<>[],. so no special syntax for comments is needed (as long as the comments don't contain the command characters). The code could just as well have been written as:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

ROT13[edit]

This program enciphers its input with the ROT13 cipher. To do this, it must map characters A-M (ASCII 65-77) to N-Z (78-90), and vice versa. Also it must map a-m (97-109) to n-z (110-122) and vice versa. It must map all other characters to themselves; it reads characters one at a time and outputs their enciphered equivalents until it reads an EOF (here assumed to be represented as either -1 or "no change"), at which point the program terminates.

The basic approach used is as follows. Calling the input character x, divide x-1 by 32, keeping quotient and remainder. Unless the quotient is 2 or 3, just output x, having kept a copy of it during the division. If the quotient is 2 or 3, divide the remainder ((x-1) modulo 32) by 13; if the quotient here is 0, output x+13; if 1, output x-13; if 2, output x.

Regarding the division algorithm, when dividing y by z to get a quotient q and remainder r, there is an outer loop which sets q and r first to the quotient and remainder of 1/z, then to those of 2/z, and so on; after it has executed y times, this outer loop terminates, leaving q and r set to the quotient and remainder of y/z. (The dividend y is used as a diminishing counter that controls how many times this loop is executed.) Within the loop, there is code to increment r and decrement y, which is usually sufficient; however, every zth time through the outer loop, it is necessary to zero r and increment q. This is done with a diminishing counter set to the divisor z; each time through the outer loop, this counter is decremented, and when it reaches zero, it is refilled by moving the value from r back into it.

 
-,+[                         Read first character and start outer character reading loop
    -[                       Skip forward if character is 0
        >>++++[>++++++++<-]  Set up divisor (32) for division loop
                               (MEMORY LAYOUT: dividend copy remainder divisor quotient zero zero)
        <+<-[                Set up dividend (x minus 1) and enter division loop
            >+>+>-[>>>]      Increase copy and remainder / reduce divisor / Normal case: skip forward
            <[[>+<-]>>+>]    Special case: move remainder back to divisor and increase quotient
            <<<<<-           Decrement dividend
        ]                    End division loop
    ]>>>[-]+                 End skip loop; zero former divisor and reuse space for a flag
    >--[-[<->+++[-]]]<[         Zero that flag unless quotient was 2 or 3; zero quotient; check flag
        ++++++++++++<[       If flag then set up divisor (13) for second division loop
                               (MEMORY LAYOUT: zero copy dividend divisor remainder quotient zero zero)
            >-[>+>>]         Reduce divisor; Normal case: increase remainder
            >[+[<+>-]>+>>]   Special case: increase remainder / move it back to divisor / increase quotient
            <<<<<-           Decrease dividend
        ]                    End division loop
        >>[<+>-]             Add remainder back to divisor to get a useful 13
        >[                   Skip forward if quotient was 0
            -[               Decrement quotient and skip forward if quotient was 1
                -<<[-]>>     Zero quotient and divisor if quotient was 2
            ]<<[<<->>-]>>    Zero divisor and subtract 13 from copy if quotient was 1
        ]<<[<<+>>-]          Zero divisor and add 13 to copy if quotient was 0
    ]                        End outer skip loop (jump to here if ((character minus 1)/32) was not 2 or 3)
    <[-]                     Clear remainder from first division if second division was skipped
    <.[-]                    Output ROT13ed character from copy and clear it
    <-,+                     Read next character
]                            End character reading loop

Portability issues[edit]

Partly because Urban Müller did not write a thorough language specification, the many subsequent brainfuck interpreters and compilers have come to use slightly different dialects of brainfuck.

Cell size[edit]

In the classic distribution, the cells are of 8-bit size (cells are bytes), and this is still the most common size. However, to read non-textual data, a brainfuck program may need to distinguish an end-of-file condition from any possible byte value; thus 16-bit cells have also been used. Some implementations have used 32-bit cells, 64-bit cells, or bignum cells with practically unlimited range, but programs that use this extra range are likely to be slow, since storing the value n into a cell requires Ω(n) time as a cell's value may only be changed by incrementing and decrementing.

In all these variants, the , and . commands still read and write data in bytes. In most of them, the cells wrap around, i.e. incrementing a cell which holds its maximal value (with the + command) will bring it to its minimal value and vice versa. The exceptions are implementations which are distant from the underlying hardware, implementations that use bignums, and implementations that try to enforce portability.

Fortunately, it is usually easy to write brainfuck programs that do not ever cause integer wraparound or overflow, and therefore don't depend on cell size. Generally this means avoiding increment of +255 (unsigned 8-bit wraparound), or avoiding overstepping the boundaries of [-128, +127] (signed 8-bit wraparound) (since there are no comparison operators, a program cannot distinguish between a signed and unsigned two's complement fixed-bit-size cell and negativeness of numbers is a matter of interpretation). For more details on integer wraparound, see the Integer overflow article.

Array size[edit]

In the classic distribution, the array has 30,000 cells, and the pointer begins at the leftmost cell. Even more cells are needed to store things like the millionth Fibonacci number, and the easiest way to make the language Turing-complete is to make the array unlimited on the right.

A few implementations[8] extend the array to the left as well; this is an uncommon feature, and therefore portable brainfuck programs do not depend on it.

When the pointer moves outside the bounds of the array, some implementations will give an error message, some will try to extend the array dynamically, some will not notice and will produce undefined behavior, and a few will move the pointer to the opposite end of the array. Some tradeoffs are involved: expanding the array dynamically to the right is the most user-friendly approach and is good for memory-hungry programs, but it carries a speed penalty. If a fixed-size array is used it is helpful to make it very large, or better yet let the user set the size. Giving an error message for bounds violations is very useful for debugging but even that carries a speed penalty unless it can be handled by the operating system's memory protections.

End-of-line code[edit]

Different operating systems (and sometimes different programming environments) use subtly different versions of ASCII. The most important difference is in the code used for the end of a line of text. MS-DOS and Microsoft Windows use a CRLF, i.e. a 13 followed by a 10, in most contexts. UNIX and its descendants, including Linux and Mac OS X, use just 10, and older Macs use just 13. It would be unfortunate if brainfuck programs had to be rewritten for different operating systems. Fortunately, a unified standard is easy to find. Urban Müller's compiler and his example programs use 10, on both input and output; so do a large majority of existing brainfuck programs; and 10 is also more convenient to use than CRLF. Thus, brainfuck implementations should make sure that brainfuck programs that assume newline=10 will run properly; many do so, but some do not.

This assumption is also consistent with most of the world's sample code for C and other languages, in that they use '\n', or 10, for their newlines. On systems that use CRLF line endings, the C standard library transparently remaps "\n" to "\r\n" on output and "\r\n" to "\n" on input for streams not opened in binary mode.

End-of-file behavior[edit]

The behavior of the "," command when an end-of-file condition has been encountered varies. Some implementations set the cell at the pointer to 0, some set it to the C constant EOF (in practice this is usually -1), some leave the cell's value unchanged. There is no real consensus; arguments for the three behaviors are as follows.

Setting the cell to 0 avoids the use of negative numbers, and makes it marginally more concise to write a loop that reads characters until EOF occurs. This is a language extension devised by Panu Kalliokoski.

Setting the cell to -1 allows EOF to be distinguished from any byte value (if the cells are larger than bytes), which is necessary for reading non-textual data; also, it is the behavior of the C translation of "," given in Müller's readme file. However, it is not obvious that those C translations are to be taken as normative.

Leaving the cell's value unchanged is the behavior of Urban Müller's brainfuck compiler. This behavior can easily coexist with either of the others; for instance, a program that assumes EOF=0 can set the cell to 0 before each "," command, and will then work correctly on implementations that do either EOF=0 or EOF="no change". It is so easy to accommodate the "no change" behavior that any brainfuck programmer interested in portability should do so.

Derivatives[edit]

Many people have created brainfuck equivalents (languages with commands that directly map to brainfuck) or brainfuck derivatives (languages that extend its behavior or map it into new semantic territory).

Some examples:

  • Pi, which maps brainfuck into errors in individual digits of Pi.[citation needed]
  • VerboseFuck, which looks like a traditional programming language, only what appears as parameters or expressions are actually parts of longer commands that cannot be altered.[citation needed]
  • Ook!, which maps brainfuck's eight commands to two-word permutations of "Ook.", "Ook?", and "Ook!", jokingly designed to be "writable and readable by orang-utans" according to its creator.[9][10]

However, there are also unnamed minor variants (or dialects), formed possibly as a result of inattention, of which some of the more common are:[citation needed]

  • forbidding, rather than ignoring, any non-command characters in brainfuck programs
  • introducing a comment marker which comments out the rest of the line
  • various alterations of the loop semantics, sometimes destroying Turing completeness
  • requiring a special character to mark the end of the program

References[edit]

  1. ^ "The Brainfuck Programming Language". Muppetlabs.com. Retrieved 2013-10-30. 
  2. ^ "Wouter's Wiki : False Language". Strlen.com. 2013-08-03. Retrieved 2013-10-30. 
  3. ^ "BRAINFCK IN 100 BYTES!". Pferrie.host22.com. Retrieved 2013-10-30. 
  4. ^ "dev/lang/brainfuck-2.lha". Aminet. Retrieved 2013-10-30. 
  5. ^ "BF is Turing-complete". Iwriteiam.nl. Retrieved 2013-10-30. 
  6. ^ "Index of /brainfuck/bf-source/prog". Esoteric.sange.fi. 2002-01-22. Retrieved 2013-10-30. 
  7. ^ "BF interpreter written in BF". Iwriteiam.nl. Retrieved 2013-10-30. 
  8. ^ "Beef –". Kiyuko.org. Retrieved 2013-10-30. 
  9. ^ Morgan-Mar, David (2009-03-21). "Ook!". DM's Esoteric Programming Languages. Retrieved 2014-06-28. 
  10. ^ Paloque-Bergès, Camille (2009). Poétique des codes sur le réseau informatique (in French). Paris: Éditions des archives contemporaines. p. 73. ISBN 978-2-914610-70-4. 

External links[edit]