Assemble kernel on the client #1

Merged
cdo merged 72 commits from client-side-assembler into main 2026-03-18 15:21:33 +00:00
Showing only changes of commit 19ef69958d - Show all commits

View File

@@ -1,31 +1,24 @@
# Wipforth # Wipforth
Wipforth is a simple Forth implementation that runs in the WebAssembly Wipforth is a Forth implementation that runs in the WebAssembly
virtual machine. It does I/O via memory-mapped peripherals, which are virtual machine. The system is bootstrapped from source on page load:
emulated in JavaScript. the only non-text file is the favicon :)
- For the Forth kernel, see [wipforth.wat](./wipforth.wat) I/O is done via memory-mapped peripherals, which are emulated in
- For the JavaScript emulator, see [emu.js](./emu.js) JavaScript.
- For the Forth prelude, which is loaded at start-up, see
[prelude.f](./prelude.f) - For the Forth kernel, see [wipforth.ws](./wipforth.ws)
- For the emulator, see [emu.js](./emu.js)
- For the assembler, see [asm.js](./asm.js)
- For the prelude (Forth code loaded right after the kernel boots),
see [prelude.f](./prelude.f)
- For a description of the peripherals, see the - For a description of the peripherals, see the
[Peripherals](#peripherals) section below. [Peripherals](#peripherals) section below.
## Building and Running Locally ## Building and Running Locally
You'll need: There's a [Guile](https://www.gnu.org/software/guile/) script in the
repo you can use for this:
- [WABT](https://github.com/WebAssembly/wabt) (not for long mwahaha)
- [Guile](https://www.gnu.org/software/guile/) (or bring your own HTTP
server -- see note below)
To run, first compile the WebAssembly module:
```
wat2wasm --enable-threads wipforth.wat
```
Then run the development server:
``` ```
guile server.scm guile server.scm
@@ -34,14 +27,20 @@ guile server.scm
You should then be able to open <http://localhost:8080> in a browser You should then be able to open <http://localhost:8080> in a browser
and use the system from there. and use the system from there.
**NOTE**: The server is very simple and just serves the files with the However, since everything is bootstrapped on the client, basically any
cross-origin isolation headers required for `SharedMemoryBuffer` use. HTTP server will do as long as it sets the appropriate response
You could use any HTTP server that sets these headers. headers for `SharedMemoryBuffer` use:
You should **definitely not** use the development server to serve the - `Cross-Origin-Opener-Policy: same-origin`
application on the open internet; I just hacked it together for - `Cross-Origin-Embedder-Policy: require-corp`
testing on localhost during development and it's probably hilariously
insecure. So, if you don't have Guile on your system you can use something else
like Python's `http.server`.
**NOTE**: You should **definitely not** use `server.scm` to serve the
application on the open internet or anything like that; I just hacked
it together for testing on localhost during development and it's
probably hilariously insecure.
## End-to-End Tests ## End-to-End Tests
@@ -62,16 +61,13 @@ Given that's all sorted, you should be able to run:
guile tests.scm guile tests.scm
``` ```
It will print a JUnit XML report to standard out, you can pretty-print It will print a JUnit XML report to standard out. You can
it with: pretty-print it with `xmllint` if you have it installed:
``` ```
guile tests.scm | xmllint --format - guile tests.scm | xmllint --format -
``` ```
Though, of course, this will require that you have `xmllint` on your
system.
## Peripherals ## Peripherals
### Terminal ### Terminal