nagisa (Nov 16 2023 at 14:23): nagisa (Nov 16 2023 at 14:23):I’m currently investigating what it would take to make runtests work on this zkasm architecture backend that we’re prototyping in cranelift. As far as I can tell currently the only supported family of runtests are the cranelift_jit based ones, is that correct? zkASM in particular is interesting in that runtests for it can be run on any host, but running those will require invoking an external process. Does that make sense, and would it be interesting to have this upstream (for e.g. qemu-based emulated tests for other architectures?)
Afonso Bordado (Nov 17 2023 at 11:19):I'm not entirely sure on what's the best way to go about this, we already have qemu based tests for the reset of the architectures, but we run the whole testsuite in qemu instead of just calling out to it in cranelift run tests.
test run calls a bunch of stuff that migh not be useful for zkASM (i.e. using cranelift-native to figure out supported ISA flags).
The closest thing that I can imagine would be test interpreter that, while it does not call an external process it does run on all arches regardless of the native ISA. So it might be a good way of doing things, creating a test zkasm. I'd like to know other peoples opinion on this is.
Afonso Bordado (Nov 17 2023 at 11:21):Also, are you guys using cranelift-jit, or would that allow you to avoid adding support there?
nagisa (Nov 17 2023 at 14:27):Getting zkasm into something that resembles a runnable state involves a couple more compilation steps from zkasm to PIL to polynomials which are then used by… an interpreter-like thing as far as I know. In that sense cranelift-jit which expects to produce machine code loadable into memory and immediately runnable is not a good match in multiple ways. Or perhaps my interpretation of it is wrong?
(We’re currently also just targeting a nodejs-written prover, so modifying cranelift-jit to support running zkasm is not really feasible at this time)
nagisa (Nov 17 2023 at 14:28):The interpret tests are interesting, I’ll look at those. Thank you for the pointer.
Afonso Bordado (Nov 17 2023 at 14:29):In that case i think having a separate test runner might be the best idea. Similar to test interpret, doing it that way you shouldn't need to work around cranelift-jit or cranelift-native to get your tests running
Note, you can still use the entire runtest suite, but just adding a different test declaration
nagisa (Nov 20 2023 at 15:18):Thank you, that was very helpful!
Last updated: Nov 22 2024 at 16:03 UTC