nagisa
commented
10 months ago I have made some headway in cleaning up the backend, but I don’t feel like I made enough progress there to mark off either of the points above as completed, unfortunately. Machine definition cleanup in particular ended up being quite tricky as I kept hitting far reaching uses of certain entities such as the zero register which necessitated rewriting large chunks of non-trivial functionality. As an example is the PR the floating/vector removal which ended up touching about 1000 lines of code, even though I went in intending to remove just the register definitions. Fortunately for floating point, all that code could be removed wholesale – zkASM simply does not support it at this time. Not as easy to do so on the integer side of things.
I have also started looking into the second point, as part of a larger effort to move our testing over to the pre-existing filetests framework. Far away from being complete, but at the very least it is already clear that there’s a non-trivial amount of work here as well.
This is a monthly initiative tracking issue.
Today our zkasm backend is largely a copy of RISC-V backend still, and it shows. It also frequently causes me have a brain spasm and misremember what and how certain functions of zkasm work. Either way, the primary thing we need to do, I think, before implementing the rest of the backend, is to get fundamentals in order:
Implementing some of the WASM operations in zkasm is going to be troublesome as well, given that we only really have some arithmetic and bitwise op instructions to work with. One thing to keep in mind here is that we don’t need a full WASM instruction set for an MVP test – which makes me think that I should also gather requirements on what the representative benchmark contracts we want to use to evaluate zkasm, and then write down the list of the operations that we want to implement.