A Brainfuck to WebAssembly compiler and playground
github.comMy first attempt was to put Jon Ripley's Lost Kingdom [1] to the input and it obviously didn't work (or took too much time, I don't know). At the very least there is an asm.js version that does work out of the box [2].
Looks like the default Lost Kingdom BF interpreter uses 8-bit cells, whereas the bf2wasm compiler uses 32-bit cells. This matters in Brainfuck; choosing the "wrong" one of the idioms [-] and [+] for zeroing a cell gets worse as cells get bigger. Maybe if you tweaked the bf2wasm compiler to use 8-bit cells?
Moreover, the Lost Kingdom interpreter will expand the memory arbitrarily as it encounters > instructions, whereas the bf2wasm interpreter has a fixed limit of 16384 4-byte cells according to its documentation.
Oh, you are right; I simply overlooked that part of the readme. In my opinion that should have been 8-bit cells mainly because AFAIK simulating 16-bit or 32-bit in 8-bit cells is reasonable [1] but doing the other way without slowing it down too much is highly dependent to the program.
[1] https://esolangs.org/wiki/Brainfuck_bitwidth_conversions
I didn't know about the idiom of using [+] for zeroing. Are the cells supposed to be signed ?
Signedness depends on your interpreter. In practice it hardly matters since there's no print function anyways, so if you want 2s complement you'll end up implementing it yourself anyways.
[+] should always overflow to 0 at some point, which is entirely doable for 8 bit, but less so for 32bit. as for choosing between [-] and [+] you'll just have to guesstimate if 0 or intmax is on average closer to your value.
> This matters in Brainfuck; choosing the "wrong" one of the idioms [-] and [+] for zeroing a cell gets worse as cells get bigger.
Translating these idioms to "*data = 0" was one of the first peephole optimizations I implemented when writing my own optimizing brainfuck interpreter.
I love it! I've been working on a brainfuck to asm.js compiler myself and it's a great learning experience, even if asm.js will be going away in favor of wasm (though I believe Chrome compiles asm.js into wasm).
I'm excited to hear about how you intend to solve input instructions. I've been struggling with that myself since I want to make it asynchronous, which might require some nasty tricks.
I guess I will add an input in the playground and copy its content to an extra wasm memory page. Then I'll track the input's index with a new local.
I realized after coding that first version that most brainfuck programs run indefinitely. Apart from Hello World, I didn't find lots of program I could run synchronously. Making it asynchronous sounds like a tough job.
Chrome does nothing with asm.js; it's Firefox who applies special, faster compilation routines to asm.js code.
It was announced in V8 6.1 that asm.js could be validated and compiled to WebAssembly. https://v8project.blogspot.se/2017/08/v8-release-61.html
To be fair I don't think this announcement ever spread that far and I don't think it was ever announced that the validation would be enabled in Chrome, nevertheless I see asm.js validation messages (or rather, invalidation messages when there's issues) in Chrome 64.
Not sure about Chrome, but the support in Chromium has already been shipped last year: https://bugs.chromium.org/p/v8/issues/detail?id=4203
Oh, so it changed! Didn't know that, thanks. When playing with Emscripten, I'm still seeing asm.js working noticeably faster in Firefox than in Chromium, so I just assumed that it's still how it was for years :)
Web assembly is now supported across all major browsers.
asm.js is not webassembly.
Honest question: why (is it beyond I was bored, so I did it because I could)?
Before WebAssembly, developers were stuck with Javascript. I wanted to show that one web developer can now code with any language he wants, brainfuck for instance.
learning by doing.
Indeed, I also learnt how WebAssembly works :)