
Design and Implementation of a 256-Core BrainFuck Computer [pdf] - Katydid
http://people.csail.mit.edu/wjun/papers/sigtbd16.pdf
======
rys
"The BrainFuck computer is an attractive solution for servicing high
throughput BrainFuck cloud services, both in terms of performance and cost."

Love it.

~~~
Cyph0n
Don't laugh: this is the next big step in cloud computing infrastructure.
Imagine Linux compiled to the BrainFuck ISA running a Docker container running
a BrainFuck web application. Of course, we will clearly need a solid
BrainFuck-to-JS transpiler to make things web scale.

Could it get better than that?

~~~
Retr0spectrum
Here's a very performant BF-to-JS transpiler:

[http://copy.sh/brainfuck/](http://copy.sh/brainfuck/)

We're ready for the revolution!

~~~
adrianratnapala
I thank you for the first good (if not correct) usage of the word "performant"
in the history of the universe.

------
qume
". A large amount of research is focusing on what kind of wimpy machines are
best fit for important workloads. In this paper, we present a rather extreme
example of a wimpy processor, using the BrainFuck [22] esoteric programming
language as its ISA."

Seems legitimate to me. Seriously, why not explore the extremes? Thats where
we often learn the most.

I suspect many here think this is a joke, but although does have it's funny
side this definitely warrants the research IMHO

------
Someone
Why is the author consistently mixing up " _" instructions per cycle"_ with _"
instructions per second"_?

Surely, phrases such as _" We observed the following Instructions per Second
(IPC)"_ and _" assuming a perfect 1 instruction per second on the general
purpose processor"_ should have activated some neurons in some brain, even
assuming it got distorted by doing this research?

~~~
sitkack
Maybe working on a 256 core BF computer has BF'd his brain? Have some empathy.

~~~
nickpsecurity
That's my guess. It's one of the few projects that I thought actually would
damage my brain. I avoided it. Unlambda language is another one like that.
Although I have considered trying to implement that one, esp in hardware.

------
qwertyuiop924
Ah. MIT, never change. Mind, this kind of stuff could come out of other
institutions as well. They shouldn't change either.

Anyways, can we have a version of TIS-100 where you write brainfuck with added
message sending primitives instead of the TIS-100 asm? Of course, each BF
interpreter would be working with only, say, 2 or 3 cells of RAM.

I want to see either that, or a TIS-100 asm compiler for GreenArray chips. Or
both.

~~~
flamedoge
"Just because you can, doesn't mean you should"

~~~
gene-h
"Just because we shouldn't doesn't mean we won't"

~~~
qwertyuiop924
"...and when we do, it's gonna be _awesome_!"

------
nickpsecurity
This is some bullshit. They didnt even port the standard benchmarks to
Brainfuck to compare performance against reference implementations. I want to
see ZIP, raytracing, web servers, map reduce... actual apps with associated
BrainFuck performance. Scratch the whole Future Work section in favor of that
given you might accidentally find evidence for using it in production
somewhere.

Moore and your GreenArray chips: be afraid! Something even more
incomprehensible is coming after your market share!

~~~
TazeTSchnitzel
I wonder if you're joking, but these sorts of things have been implemented in
Brainfuck.

~~~
nickpsecurity
I wasn't. I'm simply too sane to follow BrainFuck developments unless it's
something wild and accidentally useful like a 256-core CPU on HN front page.
;) If they've been implemented, authors should've run some of them on the
processor to include benchmarks in the paper. It's standard thing to do in
CompSci papers on CPU's, compilers, optimizations, interpreters, anything.
They usually include something like that.

~~~
TazeTSchnitzel
Right, okay. It stood out to me too, because there are compilers and larger
applications targeting Brainfuck, so it seems strange to only choose “hello
world”-style programs.

------
chris_va
I'm impressed that they were able to find 24 references to cite.

~~~
posterboy
despite the juvenile name bf is quite mature for what it is

------
faragon
After Intel adding deep-learning instructions to its processors, I guess they
could add BrainFuck extensions to the x86 ISA, too.

~~~
posterboy
All 6 BF commands have x86 opcode counterparts, already. Don't quote me, I'm
guessing.

~~~
userbinator
Not quite, but an interpreter can be written in less than 100 bytes of x86
instructions:

[http://www.hugi.scene.org/compo/compoold.htm#compo6](http://www.hugi.scene.org/compo/compoold.htm#compo6)

~~~
posterboy
The competition rules have added constraints to make the interpreter a usual
command line tool. However, with memory mapped input and output ports it
becomes a lot easier, which would be akin to 8bit micro controller
programming. Parsing would take more than one cpu instruction per BF
instruction, so the program would need to be assembled. I don't know x86 well
enough to write that, though. I imagined, there would be a single instruction
equivalent of 'x=*(p++)', but couldn't find anything like that.

In some makeshift syntax and with one instruction too much, I got:

    
    
       >, < = inc, dec al
       +, - = inc, dec [al]
       . = out output_port, [al]
       , = in [al], input_port
       [ = Label: cmp [al], #0
           jnz (Labelend + sizeof (jmp instruction))
       ] = Labelend: jmp Label
    

The labels are generated by the assembler. The ports would have to be directly
soldered to some I/O peripherie, but alternatively the input and output could
be memory mapped and fed by interrupts, as well.

------
rasur
LOL. I work in the same building as Urban. I'll be sure to point it out to him
on Monday, I'm sure he'll be amused (or annoyed at my position in the queue of
people that have already informed him of this). :D

------
noipv4
SCIGen has come a long way to producing a really realistic paper along with
the hardware implementation ;)
[https://pdos.csail.mit.edu/archive/scigen/](https://pdos.csail.mit.edu/archive/scigen/)

------
subleq
The instruction encoding seems inefficient -- they don't use the full 4 bits
of information (the first bit is always zero except for `.`). Why not use a
3-bit encoding, since there are 8 instructions?

~~~
Xorlev
They have 9 states including a stop instruction, b`1111 which would preclude a
3-bit encoding. In any case, I suspect it's much easier to handle 4-bit words.

~~~
trevyn
>I suspect it's much easier to handle 4-bit words.

I therefore suspect a 3-bit encoding would be more in the spirit of BrainFuck.
:)

------
NormlOverrated
Available on AWS in 2017.

~~~
nickpsecurity
The SystemD execution and update engine.

~~~
qwertyuiop924
I mean, it would be more secure than the current one. But that's not saying
much.

Fun fact: systemd now has an entire command devoted to setting locale,
something tyically done through simple text files.

Lennart, just stop writing executables that do almost nothing. Despite what
you may thing, we don't all have infinite disk space.

~~~
witty_username
$ du -h --apparent-size /lib/systemd/systemd-localed 336K
/lib/systemd/systemd-localed

Not much, you could fit a thousand copies of this in 336 MB.

~~~
qwertyuiop924
But it's still an entirely pointless 336K. I could use that to store:

-197 copies of nethack

-10% of DarkPlaces

-36% of GCC

-44% of ZSH

-30 copies of CPython (just the executable, of course: that's all you counted)

-10% of ZSNES

-1.36 copies of XScreenSaver

-42% of Teeworlds

All of these are more valuable uses of my precious disk space, because all of
them actually do something: They actually give me capabilities I previously
didn't have.

~~~
nickpsecurity
GCC and CPython are great illustrations of what Im talking about. Others are
good. Also, Oberon System base with kernel, files, editor, viewer, etc is
around 116KB per Wirth's paper on FPGA implementation.

So, you get a whole OS with some utilities in between 1/3 and 1/2 of SystemD
binary. Also worth noting Oberon includes safety checks, too. ;)

~~~
qwertyuiop924
Oberon might be worth checking out. I've heard neat stuff.

However, from what I've seen, it's a bit too verbose for my tastes (the
language, not the OS).

~~~
nickpsecurity
Honestly, I found the tradeoffs of it to be the most interesting. It hits an
interesting balance of readable, safe, fast compile, and fast runtime.
Includes some OOP and concurrency foundations while barely changing the
language. Whole platform can fit in one book. You could theoretically
understand whole thing and reimplement in language of your choosing. Was esp
good when hardware was weaker and more diverse. Also better starting language
than C in education as it can be easy at first with difficulty gradually
increased with intro of unsafe constructs. Finally, it's seeing some uptake in
embedded with Astrobe IDE.

So, that's a quick review. The main one you'll find is older system where A2
Bluebottle is latest. Runs fast, too.

~~~
qwertyuiop924
Neat.

Yeah, it does look really cool, just verbose. And you say it's easy to
implement....

Maybe I can get it running on my gameboy?

I kid. Sort of.

~~~
nickpsecurity
"Yeah, it does look really cool, just verbose. And you say it's easy to
implement...."

It is a compiler and OS. Easy means a different thing in this context versus
average usage in software. I'd say vastly easier than trying to understand GCC
or Linux. How about that? Also, the original version was done by 2 people and
some change. Each port of compiler was done by 1-2 people in relatively short
time. Mostly students with basic knowledge in CompSci. Helps it's well-
documented.

So, it's not easy as throwing together a web app but can't be ridiculously
hard if you take it a piece at a time. The use I had for it, other than
learning or pleasure, would be for subversion-resistent, verified-to-assembly
builds. It's super easy to learn Oberon with the OS itself straight-forward.
People could code it up in a local language, the compiler too, compile those
(or hand-done in ASM), and bootstrap into a trusted environment. That can be
used to produce the rest with compilers built on top in a memory-safe language
that handles foreign code more safely. Better, no patent suits or anything on
Wirth-based tech like .NET or Java might get you.

Other than Oberon system, Modula-3 (not Wirth) and Component Pascal (Wirth et
al) are most worthwhile to check out in terms of practical languages. BlackBox
Component Builder is still in active use with Component Pascal, esp in Russia
and Europe. They love it over there since it's got OOP & GUI with Oberon
simplicity & safety.

~~~
qwertyuiop924
Of course. I'm foolish, but not foolish enough to think "easy" compiler/OS
equals "easy" webapp. However, I am foolish enough to start any project,
although usually not mad enough to finish it once I get an idea of the work
involved.

Once again, Oberon looks neat. I am usually not a fan of the Wirthian
languages, so I might not enjoy it in the same way I enjoy, say, Python, or
Scheme, but it looks interesting.

~~~
nickpsecurity
"Of course. I'm foolish, but not foolish enough to think "easy" compiler/OS
equals "easy" webapp. However, I am foolish enough to start any project,
although usually not mad enough to finish it once I get an idea of the work
involved."

You and I are appearing to be more similar than I thought on these kinds of
things haha.

"Oberon looks neat. I am usually not a fan of the Wirthian languages, so I
might not enjoy it in the same way I enjoy, say, Python, or Scheme, but it
looks interesting."

In your case, rebooting PreScheme to do a small OS like Oberon or clone of it
might be a better take. There's already books on quickly putting together a
Scheme compiler. The PreScheme and VLISP papers are pretty detailed. Include
some safety features from Clay (C-like) and Carp (Lisp) with Scheme's macros
and simplicity. Mock-up assembly language in it so you can code & test it,
too, in Scheme with extraction process to real thing.

That combo seems like it would work better for you plus result in at least one
deliverable: a PreScheme implementation for system programming whose code was
compiled with GCC or LLVM. You might find that useful over time esp if you
made syntax compatible with one of your typical, Scheme implementations to
port those libraries over easily. Split it between GC'd code and non-GC'd code
like Modula-3 did.

~~~
qwertyuiop924
Seems neat. The original PreScheme is part of S48, which seems to be dead.

Speaking of which, I should probably consider doing that project I was
thinking of doing for a while: port SCSH to some other scheme implementations
which are actually alive.

So yeah, the trick with doing a prescheme project is that I'd first have to
build a PreScheme compiler (with added safety, etc.) and then I'd have to
build one that can run on bare metal. The former ought to be possible,
especially if I'm targeting C or LLVM (some bits might get a bit rough, but
most of Scheme is pretty easy to implement). The latter would perhaps be
possible, but making use of it would likely require a more in-depth knowledge
of the hardware than I currently possess.

You know, I was joking about porting Oberon to the gameboy, but the GBA is a
really well-defined piece of hardware with readily available tooling (which I
actually have, because you need it for LSDJ), and a good deal less complexity
than a modern x86 machine...

Man, why can't I just write videogames, like the _normal_ people?

Well, my current side project is writing a version of the Tafl-inspired board
game Thud that you can play over a network, so I guess I'm already doing
that...

~~~
nickpsecurity
"The former ought to be possible, especially if I'm targeting C or LLVM (some
bits might get a bit rough, but most of Scheme is pretty easy to implement)."

That's what they did originally. Should work.

" but the GBA is a really well-defined piece of hardware"

Then do a PreScheme wrapper on it supporting inline or calls to assembly for
performance-critical routines. See if you can make the primitives on bottom
close to how hardware works for efficiency. The AI research of the 80's
indicate it might be able to handle a board game.

------
posterboy
The [RSSB] Single Instruction Architecture is interesting for a simple
processor implementation as well. [Calfee] mentions a relation to "biological
mechanical computer", i.e. neural like.

[RSSB] [https://esolangs.org/wiki/RSSB](https://esolangs.org/wiki/RSSB)

[Calfee]
[https://github.com/nospamcalfee/RSSB](https://github.com/nospamcalfee/RSSB)

------
djhworld
The title of the paper made me laugh a lot.

Reading through it, you can tell the author had written it with a knowing
smile

~~~
qwertyuiop924
Well, this is a SigTBD paper
([http://sigtbd.csail.mit.edu](http://sigtbd.csail.mit.edu)). I would expect
nothing less.

------
r-w
Not sure whether Iota, Jot, and lambda calculus can be executed instruction-
by-instruction, but generally speaking, wouldn’t a Turing-complete language
with just two instructions allow for even greater throughput than BrainFuck
does?

~~~
rosalinekarr
Why two? Why not just one?

[https://en.wikipedia.org/wiki/One_instruction_set_computer](https://en.wikipedia.org/wiki/One_instruction_set_computer)

------
digi_owl
Whiskey Tango Foxtrot?

~~~
bbcbasic
Whiskey tango bravo foxtrot

------
toast0
Just fyi, if you put this on your resume, you might want to omit or abbreviate
the name of the language.

~~~
xvedejas
Why? "Fuck" is not as bad a word as it used to be, especially depending on
context.

~~~
veddox
And your surrounding culture. In some places, you'd be out the door before the
word had fully left your mouth. In others, nobody would blink...

------
haalcion3
Is this the most the word "fuck" has appeared in a technical paper? It looks
like it.

