In september I have been working on the architecture for “bare” Orca apps (as opposed to standalone apps that are bundled with the runtime executable). In this model, the app is distributed as a zipped folder containing the app’s resources and WebAssembly modules, and run by a trusted runtime on the user’s machine.

This also changes the distribution of the Orca environment itself, as we now have three components to distribute:

• A launcher, which can download and run apps from URLs, and also provides access to a local library of cached apps. It also handles “open” actions on bare apps (i.e. it will run app files when you double-click on them).
• The Orca runtime proper. This needs to be split from the launcher because we also want to allow bundling standalone applications, and we don’t want to bundle the whole launcher with them. It can be run by the launcher, which passes the app’s file as a command line argument. In the case of a standalone app, it is run with no argument, and finds the app’s file relative to itself. The runtime then decompresses the app’s file in a temporary folder, loads the main WebAssembly module, and starts running the app.
• The SDK and tooling needed to develop new apps for the platform. This comprises header files for the Orca APIs, a WebAssembly blob for the support library, and the commands to bundle WebAssembly modules and resources into bare or standalone applications.

Conveniently, this can be distributed as a single application which contains these three components. By default, this application opens as the launcher, but it can also be called from the command line to give access to the developper tooling and SDK. For example, on Windows you could double click on Orca.exe to open the launcher, but you could also use ./Orca.exe bundle --name MyApp main.wasm to package main.wasm into a new Orca app.

In the process of working on this, I started implementing a few utility APIs that will also become part of the SDK:

• A versatile command-line parser with subcommands, short and long options, optional/repeated/multiple argument options, automatic help messages, etc.
• A subprocess API, which allows spawing child processes, communicating with them, waiting for them, collecting their outputs and exit status. This is native-side only for now, but it will be a basis for a capability-guarded API that you can use from Wasm to call into external programs.
• I also reworked the file IO API and added a number of file system interfaces, like creating directories, copying and removing files or directory trees. Along with Reuben’s work on directory listing, this gives a more complete set of functions to work with the host file system.

That’s all for now! see you next time, and take care ~

Our custom WebAssembly backend is now merged, and replaces our previous third-party interpreter (wasm3). This gives us freedom to design the interpreter in a way that supports our integrated debugger, and will also allow us to experiment with interpreter tech and WebAssembly extensions.

The new backend is called Warm, for WebAssembly Register Machine. Upon loading a module, it performs validation and compiles its functions to a custom unstructured control flow, register-based bytecode (as opposed to the WebAssembly structured control flow stack machine model). This eliminates stack book-keeping by encoding the source and destinations operands in the instructions themselves, and unfolds control flow down to simple jumps. The virtual machine then is a dead-simple loop-over-switch interpreter.

The backend passes the core wasm testsuite. It is currently slower than wasm3 because it doesn’t use threaded code yet. So one obvious avenue for improvement is to do that, either with tail calls (what wasm3 does) or computed gotos (my preference for debuggability and readability reasons, but we’ll have to try). Another one is to do a better job at register allocation, as I chose the very simplest strategy (an infinite register file and a freelist) for this first iteration. Another thing I want to try is to have a simple template JIT, as an intermediate step towards more optimized JIT tiers.

We just landed a file enumeration API in the Orca WebAssembly SDK. This allows apps to query for all files within a given directory, which is performed in a single native call, and then iterate through them on the wasm side. An example with the C API:

void printFilesInDir(oc_arena* arena, const char* path)
{
    oc_file dir = oc_file_open(path, OC_FILE_ACCESS_READ, OC_FILE_OPEN_RESTRICT);
    if (oc_file_last_error(dir)) {
      return;
    }
    oc_file_list entries = oc_file_listdir(arena, dir);
    if (oc_file_last_error(dir)) {
      return;
    }
    oc_file_list_for(entries, elt) {
        oc_log_info("Found '%.*s' with type %d\n", oc_str8_ip(elt->basename), elt->type);
    }
}

There are still a few holes in the file IO API, but we’ll be working to flesh that out in the coming months.

In addition to regular unit/integration tests, Orca has test apps that have a special oc_on_test() hook. The runtime runs this hook and checks the exit code, relying on the app to log any failures. This can be used to test specific parts of the Orca SDK from the wasm side. These test apps are built and bundled the same way as normal Orca apps. Some recent improvements to the build system now allow bundling apps without requiring a system-wide install of the orca CLI tool. Now the CI can build and run the wasm tests just like the native tests, giving better visibility on potential SDK API breakage.

I fleshed out our Github Sponsors page and added some monthly tiers. They come with symbolic rewards, from getting a distinguishing role in the Orca Discord server, to having your name and link to your homepage listed at the bottom of the landing page of the Orca website. Higher tiers are a good option for companies that want to support Orca through Github Sponsors, and include some amount of consultancy. I also plan on later adding access to private repos to specific tiers, to share bonus content with sponsors (think tutorials, screencasts, or advanced example programs).

If you want to help our work, now is the perfect time to do so :) Thanks for your support!

Martin

We just merged the new Zig build system to replace our old Python build script. Reuben wrote about it here.

The Orca debugger is shaping up. It can pause on breakpoints and step in and out through source code or instructions, navigate call frames, and inspect most variables in unoptimized code.

I was invited on Zig Showtime to talk about Orca:

Our WebAssembly Debugger can now single step through source lines.

I started working on an integrated debugger for Orca. Here’s its very first steps, moving through the bytecode. You’ll notice it’s not WebAssembly bytecode. Instead our custom backend compiles WebAssembly to a register-based machine with jumps for more efficient interpretation (and later JIT-ing).