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 complete 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 | not directly runnable |
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 |
One shipping engine
luce_maininstall host and runtimeCold compile, warm run
A source file needs the compiler, libLLVM, a C toolchain, and somewhere to write the result—like a C source file. A current .lc needs none of them. loom luce NAME.luc keeps the artifact beside the source when writable and reuses it by content and generator identity.
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. Console, working-directory files, terminal behavior, and other capabilities therefore do not depend on who started the program. The start archive turns run status into process exit status and renders the same trap/error forms.
What does not ship
The MIR interpreter exists only in the specification test target. It has no product command, environment toggle, or fallback role. Keeping it out of both binaries is a structural build property, while running every spec through it keeps it useful as an independent oracle.