Skip to main content

Emulation

 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.


Comments

Post a Comment

Popular posts from this blog

About Phidias

Phidias is a RISC V based home computer design, which should run on non RISC V platforms as well. Design ideas are here on github This blog is pretty much progress notes, assuming I make any :)
Post a Comment
Read more

Generation

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.
Post a Comment
Read more

Verification

Even though the CPU is relatively simple, I still want to verify it. I've got two Java emulators, which seem to work okay .... ish. One seems to be more established and supported (RARS) so I will verify against that.  Jupiter has the option to dump code and data so it can operate as an assembler, so I use that to generate object code (a text file of hex constants, but it'll do) So Plan 9 is to write some Python scripts to generate verification code using a seeded RNG, so I can reseed it if there's a problem. I've got a skeleton so far, but no actual code in it, yet. Then I'll write a reference emulator in Python to check I understand how the RV32I instructions work, which look relatively straightforward.  Then I'll write a proper emulator in C, verify that, and start on the design and implementation of the quasi-assembler. L8R: I have a Python emulator that mostly seems to work .... it probably doesn't :( only missing the load and store instructions which wi...
Post a Comment
Read more