Made reasonable progress today. Implemented the rest of the test harness, and verified that, just a couple of minor errors (got SLT and SLTU swapped), then it passed okay. Then I dragged out my emulator framework and tweaked that so it is suitable for RV32I, and that too is running, loading in verifier code and running it. Though I haven't run the full verifier yet, just the wrapper code. It should run though. The debugger and everything is all set up, and its the same as my other debuggers. Once I've verified the emulator, which shouldn't take long, then the next thing to think about is the assembler thing. I'm considering a sort of FORTH type design, no stack though, but with words, some of which are user defined and some of which do other things, like if/else/endif does say. The downside is that the developer cannot write their own code to generate code, macros should be possible though, but the code generating stuff will have to be in Python.
So I finished the verification generator and it seems to run pretty well, and validates on RARS. When experimenting with MUL I found that Jupiter isn't actually generating the right mnemonics, I'm not entirely sure what's going on, if it's generating RV64i equivalents - doesn't seem to be.But for things like ADD the upper 7 bits are zero and they're not. Probably make sense when I get further into RISC V. Then I wrote a fairly standard emulator generator that produces C. I reduced the basic opcode to 256 ; every rv32i opcode ends in 11, so that's 5 bits from that and 3 function bits. This way I can make the code generator in the case statement use a jump vector table rather than some lookup nonsense. Next up is to get the 'C' code verified, then build that into something resembling an emulator. L8R: I have the generated C code compiling and most of the support code written. Should get some code running in C, including the verifier hopefully tomorrow.