Interpreting RV bytecode in zkc has a nontrivial overhead: @DavePearce found that RV opcode processing requires, on average, 180 zkc instructions. A good chunk of that [how much ?] is due to RV instruction decoding in the zkc-interpreter.
Once and for all instruction decoding would perform a one time decoding of (most likely) all opcodes in the .text section. The guest program [as RV bytecode] will weigh in the tens of kilobytes [?] and thus in the tens of thousands of RV instructions. Execution will likely take 100's of millions of RV instructions. The continual re-decoding of instructions [as done atm] thus has a large impact and getting rid of it may have an immediate and meaningful performance impact.
Interpreting RV bytecode in zkc has a nontrivial overhead: @DavePearce found that RV opcode processing requires, on average, 180 zkc instructions. A good chunk of that [how much ?] is due to RV instruction decoding in the zkc-interpreter.
Once and for all instruction decoding would perform a one time decoding of (most likely) all opcodes in the
.textsection. The guest program [as RV bytecode] will weigh in the tens of kilobytes [?] and thus in the tens of thousands of RV instructions. Execution will likely take 100's of millions of RV instructions. The continual re-decoding of instructions [as done atm] thus has a large impact and getting rid of it may have an immediate and meaningful performance impact.