

A Brainfuck CPU in FPGA - gebe
http://gergo.erdi.hu/blog/2013-01-19-a_brainfuck_cpu_in_fpga/

======
iwwr
[-]>[-]< >+++++++++[<+++++++++>-]<++++++. >++++[<++++>-]<\--.
>++++++++[<\-------->-]<\-----. >+++++++++[<+++++++++>-]<\---. >+++[<\--->-]<.
. -. >++++++++[<\-------->-]<\----. >+++++++++[<+++++++++>-]<+++.
>++[<\-->-]<-. >+++++++++[<\--------->-]<++. >++++++++[<++++++++>-]<+++++++.
>+++[<+++>-]<-. >+++++++++[<\--------->-]<++. >++++++++[<++++++++>-]<++++. +.
. >+++[<+++>-]<++. >+++[<\--->-]<\--. >++++[<++++>-]<\---.
>+++++++++[<\--------->-]<.

~~~
sp332
Decoder: <http://www.iwriteiam.nl/Ha_bf_online.html>

------
lawn
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...](http://stuff.mit.edu/afs/sipb/project/corewars/koth/doc/ICWS-88)

~~~
46Bit
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 :-)

~~~
jacquesm
Digilent has some pretty neat stuff, it beats the crap out of doing your
microcode with 1n914s.

------
kimmel
Every time someone implements something new in Brainfuck it makes me smile.

Where is your god now, high level language snobs? ;)

~~~
dons
Where? ... Specifying yr cpus, of course...

[https://github.com/gergoerdi/brainfuck-cpu-
fpga/blob/master/...](https://github.com/gergoerdi/brainfuck-cpu-
fpga/blob/master/src/CPU.hs)

------
s_kanev
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.

~~~
supahfly_remix
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?

~~~
dons
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).

~~~
s_kanev
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).

------
StavrosK
Isn't Brainfuck, pretty directly, a Turing machine? It just has the added
complexity of incrementing/decrementing states rather than setting them
outright.

~~~
kryptiskt
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.

