We won’t call it useless, but we will ask why [Dan] wrote a brainfuck interpreter for the AVR
It’s not generating code for the AVR; think of it more as a bootloader. To run a brainfuck program, [Dan] uploads it to the EEPROM inside his ATMega32, after which the microcontroller takes over and starts performing whatever instruction the brainfuck program tells it to do. Because the whole thing runs off the EEPROM, the code size is limited to 1022 bytes. Enough for any brainfuck program written by a human, we think.
As for why [Dan] would want an AVR to build an interpreter for a language that is nearly unreadable by humans, we honestly have no idea other than the common, ‘because it’s there’ sentiment. There are some pretty cool projects out there that use brainfuck, including this genetic algorithm software developer. Right now, though, blinkey LEDs are enough to keep us happy, so you can see a video of brainfuck doing its thing on a LED bar display after the break.
12 thoughts on “Interpreting Brainf*#k On An AVR”
Could make a Brainf*#kduino.
“Because the whole thing runs off the EEPROM, the code size is limited to 1022 bytes. Enough for any brainfuck program written by a human, we think.”
You were wrong:
Could fit a bigger program if it were bit-packed. brainfuck uses only 8 characters, so 3bits per char is good enough for it. so he could store a 2725-instr program instead of 1022 then
And the tendency for many >>>> or <<<< in a row makes it a great candidate for run-length encoding, which would up the usable code size even more.
But, sadly, would no longer be “brainfuck”, but some derivative language.
someone had a bit of fun writing this post :D
As a side note, I do know that a BF hardware machine has been implemented in silicon and used for a commercial product (I am not at liberty to say in what and what it was for). Performance wasn’t that great but it didn’t need to be. The simplistic processor and redundant code sequences allowed for a very very small transistor count once ROM folding and other reduction techniques were used. In the end they had a very cheap chip that used very little power.
I had to go check what Brainf**k was, and as soon as I saw it thought “WOW, that would be REALLY easy to implement in hardware.”
Now I’m thinking, “What if” you got one of those huge 1ghz gate arrays and put THOUSANDS of BF CPUs on it?? Yup, could do only simple crap per clock cycle, but massively massively parallel? Could be interesting… might be memory hungry, but it’s what, $10 a gigabyte these days?
Of course to do any “real” programming on it, you might wanna use a C to BF interpreter or something :-D
I’m wondering actually if you could implement a processor with basically just a ROM. Thinking is a little foggy this morning, but thinking you could make it work like diode resistor logic, but could have fan out problems with that. Though also abusing a display array would be fun. Either a LED matrix or a TFT… hmmmm….
>Now I’m thinking, “What if” you got one of those huge
>1ghz gate arrays and put THOUSANDS of BF CPUs on it??
Or just use all of the hardware units like DSP slices and stuff that high end FPGAs have already…
This is the logically consistant controller setup for a “most useless machine”. Then, the only remaining task would be writing the user manual in lojban, so that it would be as internally consistant as the machine itself.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)