A Brainfuck CPU in FPGA(gergo.erdi.hu)
gergo.erdi.hu
A Brainfuck CPU in FPGA
http://gergo.erdi.hu/blog/2013-01-19-a_brainfuck_cpu_in_fpga/
16 comments
[-]>[-]<
>+++++++++[<+++++++++>-]<++++++.
>++++[<++++>-]<--.
>++++++++[<-------->-]<-----.
>+++++++++[<+++++++++>-]<---.
>+++[<--->-]<.
.
-.
>++++++++[<-------->-]<----.
>+++++++++[<+++++++++>-]<+++.
>++[<-->-]<-.
>+++++++++[<--------->-]<++.
>++++++++[<++++++++>-]<+++++++.
>+++[<+++>-]<-.
>+++++++++[<--------->-]<++.
>++++++++[<++++++++>-]<++++.
+.
.
>+++[<+++>-]<++.
>+++[<--->-]<--.
>++++[<++++>-]<---.
>+++++++++[<--------->-]<.
Interesting!
I had a run in with FPGA's in school in a course where we were tasked with building "a digital device". Initially we planned to make a CPU which ran brainfuck, but in the end we made one which ran Redcode and fulfilled the corewars 88 standard [1].
I'm by no means a hardware fantast, but it was still extremely fun to build. We made a microprogrammed processor with accompanied assembler. An exercise I recommend to everyone.
[1]: http://stuff.mit.edu/afs/sipb/project/corewars/koth/doc/ICWS...
I had a run in with FPGA's in school in a course where we were tasked with building "a digital device". Initially we planned to make a CPU which ran brainfuck, but in the end we made one which ran Redcode and fulfilled the corewars 88 standard [1].
I'm by no means a hardware fantast, but it was still extremely fun to build. We made a microprogrammed processor with accompanied assembler. An exercise I recommend to everyone.
[1]: http://stuff.mit.edu/afs/sipb/project/corewars/koth/doc/ICWS...
Definitely agree about building a CPU. I keep meaning to get my hands on a hobbyist FPGA. I used them a little last year before I dropped Uni, and really want to get back to it.
For now I'm satisfying myself with plans for a diode-matrix-microprogrammed CPU :-)
For now I'm satisfying myself with plans for a diode-matrix-microprogrammed CPU :-)
Digilent has some pretty neat stuff, it beats the crap out of doing your microcode with 1n914s.
This is the indirect goal of the Nand2Tetris curriculum: http://www.nand2tetris.org/
Every time someone implements something new in Brainfuck it makes me smile.
Where is your god now, high level language snobs? ;)
Where is your god now, high level language snobs? ;)
Where? ... Specifying yr cpus, of course...
https://github.com/gergoerdi/brainfuck-cpu-fpga/blob/master/...
https://github.com/gergoerdi/brainfuck-cpu-fpga/blob/master/...
I'm a bit surprised by the workflow. While I agree that hardware description languages are terrible from a software developer point of view, to me Verilog is typically much more tolerable than VHDL. Also, in the last few years, SystemC has been getting much more popular as the high-level step before Verilog/VHDL.
I wondered the same thing. From the github link, I don't see the advantage of Lava over Verilog or VHDL, both languages designed for describing hardware. Maybe Haskell provides some compiler guarantees?
Generally, people use these high-level HDLs, like Lava or Cryptol, because:
- faster design time, as you write less code to get the same things done
- reusable high level specifications
- access to high level optimizations not easily possible on the VHDL level
- easier to formally verify the high level spec matches implementation
(Aside, I used to work for a company that designed and sold these types of toolchains).
- faster design time, as you write less code to get the same things done
- reusable high level specifications
- access to high level optimizations not easily possible on the VHDL level
- easier to formally verify the high level spec matches implementation
(Aside, I used to work for a company that designed and sold these types of toolchains).
These are all valid points for high-level languages in general. One can add easier parametrization to the list (high-performing HDL code can be terrible to reparametrize).
I was mostly surprised by the choice of a Haskell-based DSL. I think such languages miss their target audience. Most people writing in an HDL are hardware designers without significant software training (I am fortunate to be a software-turned-hardware person). For them making the jump to, f.e. a functional paradigm (as in Bluespec), is much harder compared to a lesser, more popular evil (C/C++ based DSLs like SystemC or AutoESL).
I was mostly surprised by the choice of a Haskell-based DSL. I think such languages miss their target audience. Most people writing in an HDL are hardware designers without significant software training (I am fortunate to be a software-turned-hardware person). For them making the jump to, f.e. a functional paradigm (as in Bluespec), is much harder compared to a lesser, more popular evil (C/C++ based DSLs like SystemC or AutoESL).
Interesting...where do you recommend starting to learn more about these languages (books, open source languages, etc.)?
Isn't Brainfuck, pretty directly, a Turing machine? It just has the added complexity of incrementing/decrementing states rather than setting them outright.
I always liked that Brainfuck was nasty and impractical because it was very simple, and not because it was obtuse like many other esoteric languages.
It is very close to being a TM, but there are differences, because of the way you describe the DFA in Brainfuck in contrast to a TM.
Also, TMs are not entirely formal in the sense that there exists multiple TMs which all are equivalent - but there is no correct implementation. So when people say TM, or even BrainFuck, then it is not entirely clear what machine they mean.
Also, TMs are not entirely formal in the sense that there exists multiple TMs which all are equivalent - but there is no correct implementation. So when people say TM, or even BrainFuck, then it is not entirely clear what machine they mean.