Update README

This commit is contained in:
2026-03-18 14:36:47 +00:00
parent 0a52388030
commit cdff1dbdbb

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 is simple [Guile](https://www.gnu.org/software/guile/) script
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,18 @@ 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 Since everything is bootstrapped on the client, you only need an HTTP
cross-origin isolation headers required for `SharedMemoryBuffer` use. server, so if you don't have Guile on your system you can bring your
You could use any HTTP server that sets these headers. own. The only requirement is that it sets the cross-origin isolation
headers required 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. 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 +59,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