0.5.0–0.6.0 — Making It Actually Run

Generating correct bytes is one kind of confidence. Watching a CPU execute them and produce the expected result is a much stronger one.

0.5.0 — Linux execution

18b0a05 — Update project version to 0.5.0, enhance README with version history, and add Linux execution example added an x86-64 Linux runner example: allocate executable memory, copy in the bytes from generated.h, cast the buffer to a function pointer, and call it. For mov eax, 40+2; ret;, this is the moment the project could demonstrate — not just assert — that its encoder was correct: the call returns 42.

This runner is explicitly not part of the assembler. Execution lives in example code; Kasm itself only ever produces data. That separation of concerns (assembler vs. loader/runner) is a recurring theme — it shows up again later when load-time relocation and COFF output are added, both of which extend what a runner or linker can do with Kasm’s output rather than adding execution to Kasm itself.

0.6.0 — The same trick on Windows

Version 0.6.0 (recorded as a development milestone in the README’s version table) ported the runner concept to Windows x86-64 using the platform’s executable-memory APIs, proving the generated bytes were host-OS-agnostic — Kasm doesn’t encode anything OS-specific, only raw x86-64 instruction bytes.

With execution now demonstrated on two platforms, the project’s next problem became obvious: a single mov/ret pair isn’t a program, it’s a demonstration. Multi-instruction control flow needed labels, and labels needed layout — the subject of the next chapter.