83 lines
3.7 KiB
Markdown
83 lines
3.7 KiB
Markdown
|
---
|
||
|
|
title: Introducing jibniz, a web editor for IBNIZ
|
||
|
|
description: jibniz, my web editor for IBNIZ, is now feature complete
|
||
|
|
draft: true
|
||
|
|
---
|
||
|
|
|
||
|
|
I found out [my web editor][jibniz] 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.
|
||
|
|
|
||
|
|
- [Website](https://github.com/viznut/IBNIZ)
|
||
|
|
- [Documentation](https://github.com/viznut/IBNIZ)
|
||
|
|
|
||
|
|
|
||
|
|
## 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][jibniz].
|
||
|
|
|
||
|
|
### 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.
|
||
|
|
|
||
|
|
[IBNIZ]: https://github.com/viznut/IBNIZ
|
||
|
|
[jibniz]: https://flupe.github.io/jibniz/
|