
		Brainfunct
		==========

		Brainfuck revived

Introduction

	When I spotted the bf language in the archives of Cats Eye
	Technologies, I got immediately fascinated. I found out,
	however, that the only implementation left for bf was the
	interpreter -- which, all respects to Urban, was not too
	efficient a way to run bf programs.

	I thought about the task for a while and at last I realised I
	had to try it -- to make a good, optimising compiler for bf
	programs. Compiling to C was an obvious choice, not only for
	gcc optimisations, but also because of portability. Bf idioms,
	however, are so peculiar even for simple tasks, that I decided
	to write some own optimisations, too. This has also the
	advantage that the C programs take much less time to compile.

	The compiler is still in experimental stage. It has no bugs as
	far as I know; but see section `problems' for things I'd like
	to add to it.

	I found the obscene name was bad humor; my apologies for
	changing it. People may call both products, the interpreter,
	bfi (which is not written by me) and the compiler, bfc (which
	is my code) either of the names. For my own purposes, I will
	use `brainfunct'.

Changes

	There's no longer any debug command. I'll implement that if I
	have the time to do that. One useful feature has been added:
	`,' will set the location to zero on EOF. This should be an
	acceptable aid, because the value of EOF depends on the
	environment and testing for EOF in programs would make them
	unportable.

Usage

	bfc < prog.b > prog.c 2> /dev/null
	gcc -o prog -O3 prog.c

	The compiler dumps tons and tons of debug output into
	stderr. I had no time and no will to make an option not to
	give the debug output. (What's better, it will irritate the
	users of the bad'n'broken (t)csh.) The debug output might be
	useful, actually -- you can learn much about your bugs and
	common techniques by looking at it.

	The possible usages include: any mathematical problem, string
	processing (but see `problems'), entries to IOCCC, etc.

Help

	The file named `varia.b' contains some examples of ways to do
	simple operations in bf. They are not as well-written as one
	could hope, but they do show the basic ideas. For mathematical
	problems, it is advisable to use the space like a result stack
	-- and, maybe, for other problems, too. 

	As a general rule, when you are thinking about how to do
	something, always remember these things: 1. The only absolute
	operation is []. The best example of this is CLR [-] or
	[+]. 2. Flow control always zeroes some location. For this
	reason, if you want to do a conditional with a value and
	retain the value, you must DUP it. 3. If you have
	variable-size data, interleave it with empty locations. This
	will allow for transfering miscellaneous data over the
	variable-size data.

Problems

	While being Turing-complete, brainfunct is not too
	friendly. There is no way to do subroutine calls, so if you
	have to do the same thing in different contexts, you have to
	write the code again. In the long run, this will lead to
	unmaintainable programs (just compare a regular expression
	matching all forms of all regular french verbs to a program
	that does the same thing).

	This problem, which is perhaps the most severe of them all,
	could be avoided with some kind of jump instruction. But I
	haven't decided on the best way to do this, so I haven't done
	anything yet. Ideas and suggestions are welcome.

	Another problem is that processing of variable-size data and
	especially of large input chunks is almost unbearably
	hard. One could argue, of course, that if it _can_ be done, it
	shouldn't be made too easy. In some aspects, this is true. But
	I find brainfunct such an elegant language that it really
	should be given something to handle variable-size data
	elegantly, most preferably a computed move instruction. True
	fanatics could leave that instruction unused (or, better yet,
	leave `<' and `>' unused). Again, suggestions are welcome.


Panu Kalliokoski
Toppelkaengeri/bc!
pkalliok@cs.helsinki.fi

