> For the complete documentation index, see [llms.txt](https://maru-2.gitbook.io/maru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://maru-2.gitbook.io/maru/maru-zkvm/instruction-set-architecture.md). # Instruction set architecture As the zkVM processor is just a set of constraints by which rows are changed in response to instructions execution, the usual size of instruction set question presents quite unusual possibilities. While it’s true that each new instruction added to the set will bring additional complexity, with a clever column layout, new instructions cost may vary greatly. Parts of constraints, already introduced by previously added instructions can be reused almost freely. Also actual instructions execution time is neglectable compared to proving costs, so more complex instructions can greatly decrease trace size, actually improving performance. On the other hand, bloating the instruction set will still call for bigger instruction size and would definitely increase overall complexity, as even opcode selection itself would become rather complicated. Our instruction set was originally restricted to very basics of what would make the processor work - RISC core with only arithmetic operations, conditional jump and call/ret. But with the infrastructure needed for this bare set of instructions, we decided to go a little bit further and actually exposed quite a number of instructions, derived from constraint combinations of the basic instruction set. This extended set of instructions seems to reduce strings of instructions, produced by more sophisticated pointer manipulations, but it’s still quite experimental and was introduced only because it had almost no implementation cost. Also we introduced peripherals - native modules, having a memory-mapped interface and helping to extend the instruction set without bloating instructions itself. From the instruction execution point of view peripherals are free, as processed data just appears in memory, already proven. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://maru-2.gitbook.io/maru/maru-zkvm/instruction-set-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.