Architecturealpha

The parts of moxzi, how a .mo file becomes a running actor, and why the same compiler runs everywhere.

moxzi has two parts: a Motoko compiler, and a runtime that executes compiled actors with Internet Computer semantics. Both are used by every tool.

The compiler is an actor#

The compiler is written in Motoko and compiled to compiler.wasm. It isn't an ordinary program with a main function: it's an actor, with methods to upload files, start a compile job, and advance that job one step at a time. The linker, linker.wasm, is an actor too.

So anything that can run a Motoko actor can run the compiler:

Because it's the same compiler.wasm in each case, the output is the same.

The runtime#

The runtime executes actors with the Internet Computer's rules: one message at a time per actor, rollback when a message traps, await between actors, timers, cycles, upgrades and HTTPS outcalls. It's written once, in Rust, and used by:

From source to running actor#

1. Collect sources. moxzi follows imports and asks mops where packages are. moxzi deps shows the result.
2. Upload. The sources go into the compiler actor's file system, under /src/ and /pkg/.
3. Compile. moxzi starts a job and calls step until it finishes. The result is an unlinked module.
4. Link. The linker adds the Motoko runtime system, and any native kernels the application opted into, and produces a deployable module.
5. Run. Install the module on the IC, host it with moxzid, load it in a page, or run it on an actor platform. The bytes are the same in each case.

moxzi build does steps 1 to 4 and prints the hash of the compiler that did the work.

Limitations#