first draft on jibniz post
This commit is contained in:
flupe
parent
e0df45ac50
commit
c34b8a14c5
|
|
@ -90,9 +90,11 @@ a.footnote-ref sup::after { content: ']' }
|
|||
a {
|
||||
color: inherit;
|
||||
font-weight: 400;
|
||||
text-decoration: none;
|
||||
box-shadow: 0 1px 0 rgba(255, 255, 255, 0.5);
|
||||
}
|
||||
|
||||
a:hover {text-decoration: underline}
|
||||
/* a:hover {text-decoration: underline} */
|
||||
|
||||
hr {
|
||||
border: none;
|
||||
|
|
@ -129,6 +131,8 @@ strong {
|
|||
margin: 1em 0 0;
|
||||
}
|
||||
|
||||
#hd a {box-shadow: none}
|
||||
|
||||
#hd > section {
|
||||
max-width: var(--width);
|
||||
margin: 0 auto;
|
||||
|
|
@ -244,7 +248,11 @@ header.project ul li {
|
|||
}
|
||||
|
||||
main blockquote {
|
||||
font: 16px serif;
|
||||
border-left: 2px solid var(--darker);
|
||||
margin: 1em 0;
|
||||
padding: 0 1em;
|
||||
opacity: 0.8;
|
||||
line-height: 1.5;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
---
|
||||
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/
|
||||
|
|
@ -7,12 +7,14 @@ labels:
|
|||
license: MIT
|
||||
---
|
||||
|
||||
**jibniz** is a javascript implementation of the IBNIZ virtual machine.
|
||||
IBNIZ is an esoteric stack-based programming language created by _, in which every
|
||||
**jibniz** is a javascript implementation of the [IBNIZ] virtual machine.
|
||||
[IBNIZ] is an esoteric stack-based programming language created by viznut, in which every
|
||||
instruction is one character long. The code is intended to be ran for each
|
||||
pixel on a 256x256 screen, at every frame --- making it possible to produce
|
||||
animations and interactive demos.
|
||||
|
||||
[IBNIZ]: http://viznut.fi/ibniz/
|
||||
|
||||
## Limitations
|
||||
|
||||
- Currently, this implementation **does not support audio**.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
let
|
||||
compiler = "ghc884";
|
||||
rev = "b78e08e981a9ad31036fc6c6fb880c1315b4ebea";
|
||||
overlay = _: pkgs: {
|
||||
haskellPackages = pkgs.haskellPackages.override {
|
||||
overrides = self: super: rec {
|
||||
|
|
@ -8,9 +6,6 @@ let
|
|||
};
|
||||
};
|
||||
};
|
||||
nixpkgs =
|
||||
import (builtins.fetchTarball {
|
||||
url = "https://github.com/NixOS/nixpkgs/archive/${rev}.tar.gz";
|
||||
}) { overlays = [ overlay ] ; };
|
||||
pkgs = import <nixpkgs> { overlays = [ overlay ]; };
|
||||
|
||||
in nixpkgs.haskellPackages.callPackage ./site.nix {}
|
||||
in pkgs.haskellPackages.callPackage ./site.nix {}
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ executable site
|
|||
, Templates
|
||||
, Readings
|
||||
, Route
|
||||
build-depends: base >= 4.12 && < 5
|
||||
build-depends: base
|
||||
, filepath
|
||||
, achille
|
||||
, data-default
|
||||
|
|
|
|||
Loading…
Reference in New Issue