3.7 KiB
| title | description | draft |
|---|---|---|
| Introducing jibniz, a web editor for IBNIZ | jibniz, my web editor for IBNIZ, is now feature complete | true |
I found out my web editor for the IBNIZ esoteric programming language had been included in the README of the official IBNIZ repository last february. This motivated me to actually finish the implementation and make it feature complete. This post is a quick introduction to IBNIZ and explains some of the machinery involved in running IBNIZ programs in a web browser.
IBNIZ
IBNIZ is both an esoteric language created by viznut and the VM to run it. They are designed for creating audio and video demos with very terse code.
jibniz
jibniz is a project I started around 2017. The goal being to run IBNIZ programs interactively in the web browser. Even at the time, there already existed a javascript implementation. However I found the performances to be lacking and some features were --- and still are --- missing. So I decided to make my own implementation as an exercise.
You can try the live editor here: jibniz editor.
How it works
We could simply interpret the code each time we need to evaluate it. This is insufficient and has terrible performances. Therefore, we compile the IBNIZ code itself to javascript. That is, we replace each instruction by a piece of javascript code that manipulates the stack directly.
Features and known limitations
Right now, jibniz is almost feature-complete. The only missing instruction is
the sequencial data fetch G. I actually have found no code featuring this
operator, but it makes me a bit sad to not support it.
The reason is quite simple: in javascript, when using typed arrays, the
endianness is the one of the host computer, most likely little-endian.
What this means is that if a 32-bit word 0xAABBCCDD is to be stored in memory,
the bytes will end up in the following order: DD CC BB AA. This is not a
problem per se, but then there's this paragraph in the official documentation:
When a program is started, the memory is filled with the contents of the data segment without any alignment.
That is, when raw data is provided at the end of some code, it should be put
as is in the memory of the VM. If we extrapolate, this means that 32-bit words
given raw by the user would thus be stored as big-endian. Which would lead to
unexpected results when fetching whole words from memory. Currently, what
jibniz does is split the raw data segments into 32-bit words, and store them
using the host endianness. This plays nice with memory instructions like @
that fetch whole words, not so much with G, the only instruction that reads a
custom number of bits from memory.
A possible fix would be to use a DataView on the VM memory buffer rather than
a Int32Array, and read whole words by calling DataView.getByte 4 times, thus
ignoring endianness --- or rather being explicit about it.
Compiling to WASM
Even if performances are decent, I wanted to take a stab at compiling to
Webassembly early on. Sadly, IBNIZ has a very specific feature that makes it
hard to produce WASM: the jump instruction J can jump anywhere in the code,
depending on the address found on the top of the stack. In practice, I wasn't
able to find code examples where jump addresses weren't the typical addresses
left by loop operators such as X and [, but if we follow the specification,
it must be allowed.
In WASM however, jumps are well-structured. That is, you can only jump to previously defined labels, and labels are statically defined at compile-time.