From MIR to a running process
After MIR, the program becomes ordinary native files: LLVM IR, an object, a linked artifact, and mapped machine code. Start with the full walkthrough, or inspect the file and loader boundaries below.
Follow one program from source to ARM64 →
Three native products
| Command result | What it is | Who finishes it | How it runs |
|---|---|---|---|
FILE.o | relocatable native object | the user or another linker | serves as input to a linker |
FILE.lc | loadable native library with runtime and artifact tag | luce + platform linker | loom validates, loads, finds luce_main, calls |
FILE | standalone native executable | luce + platform linker + start archive | the operating system starts main, which calls luce_main |
The artifact run path
luce_maininstall host and runtimeCold compile, warm run
A cold run compiles source with the compiler, libLLVM, and the platform toolchain. A warm run validates and loads the existing .lc. loom luce NAME.luc keeps the artifact beside writable source and reuses it when its content and generator identities match.
Cold
compile source → serialize MIR → lower through LLVM → emit object → link .lc → validate and load
Warm
read tag → compare machine, ABI, content, generator → dlopen → symbol lookup → one call
Who supplies the world
loom and standalone executables build the same concrete LuceHost from shared app code. This gives both products the same console, working-directory files, terminal behavior, and other capabilities. The start archive turns run status into process exit status and renders the same trap/error forms.
The interpreter’s test role
The specification test target contains a MIR interpreter. Every program specification runs through both this interpreter and the native path, then compares their observable results. Product binaries use the native path described above.