awygle / magic Goto Github PK

Implement my perfect-hash-function-based SIMD decoder for the VR4300. This will be used for decoding basic blocks for the JIT, eventually.

I really enjoyed this blog post about Reverse Linear Scan Register Allocation. We should use one of these.

Since we need to have the code in SSA format to do this properly, this is blocked on #14 .

In preparation for a JIT, we'll need a decompiler from MIPS to an SSA representation of the code. From there we can do register allocation, perhaps some minor optimizations, etc. It's basically the first step in any real compiler we'd write.

Some pipeline stalls (the ones that depend only on instructions in the same basic block) are easy to see coming a mile away. We should be able to detect these simple cases and modify the execution tokens or JIT blocks we emit to take them into account. Obviously this won't be possible for every stall or exception, but certainly for some.

The eventual JIT will need an AMD64 instruction emitter. We could use something like asmjit that already exists, but I feel this is a valuable add to the Rust ecosystem - it should probably even be its own crate.

I propose we generate this emitter from the asmjit assembly database rather than hand-coding every instruction.

Even though Windows can't use it, I'd still like to write a "fastmem" mmap-based MMU for the Linux build at some point. We may be able to run it in WSL 2 or something down the line.

This might require enhancements to the mmap crate.

We need some kind of emulation of the latency of a cache miss that has to hit main memory. It would be pretty complex to implement a full model of the RDRAM to make this 100% accurate, so for now we'll do what CEN64 does and assume the delay is 38 cycles. This issue will remain open until either we implement that RDRAM model and have verified cycle-accuracy or we decide we don't need to care for some (good) reason.

The intent is for this emulator to have a comprehensive suite of integrated tests which are run against the emulator and the original hardware in an automatic way. This will both prevent regressions and ensure accuracy.

My proposed technical approach for this is to use the 64Drive with the TASTM32 to remotely control the original hardware and collect test results.

This issue is currently blocked (for me) on receiving my 64Drive.

Clippy and rustfmt should both be run. I need to get the main magic crate into a less work-in-progress state first, then we'll do this.

The decoders should be exhaustively verified to prove that they always produce the correct instruction and operands.

This depends on at least #5 and #4, and eventually #6 as well.

Implement the MMU using the techniques described in this presentation. I'm not sure yet whether the larger "regions" (cached, uncached, etc) should be implemented this way, as they're a bit different than the TLB stuff.

The current plan for the core emulation loop is to use an execution engine based on a ring buffer of deques. Each computational component can push execution tokens (essentially micro-operations, but sort of turned sideways) into one or more deques. The deques represent operations to be performed during a clock cycle. When the deque is empty, the next clock cycle begins.

Generate all legal VR4300 instructions from the mipsiii.json database. Ideally this would be done as a const function returning an iterator. Can you even do that in Rust today? If not, a non-const function is probably fine since this is probably only used for testing anyway.

First use will be to comprehensively verify the instruction decoder.

Implement the GDB remote debug protocol in the emulator to allow debugging as though it were a MIPS system. Probably have to host on multiple ports to separate the CPU and RSP?

To start with, the RDP will be software-based - ultimately the rendering may be moved to Vulkan compute shaders, but a software renderer will be easier to get right at first.

My preliminary implementation proposal for the renderer is based on this blog post. I'd like the software renderer to look as much like a modern GPU pipeline as possible, including vertex and fragment shaders, although that's probably more complex and probably not necessary.

There's no need to really start on this until we get to a point where something's trying to talk to the RDP.

I'd like to use slog for logging for this project. I'd also like to be able to log absurd amounts of data - think every instruction, every register modification, that kind of thing. I think this will require a new slog sink which lives on the other side of a crossbeam channel or something. slog-async exists and I think is basically what we want but perhaps not full-featured enough.

We should really test this in CI. Maybe CircleCI, Travis CI, or Azure Pipelines? Regardless we should run tests, run rustfmt, and run clippy before accepting PRs.

This also means I'll have to start using PRs... which is probably for the best.

We also need to emulate the DCache.

Scalar implementation of an instruction decoder for VR4300 instructions. Ideally, implement the classic chained-table-lookup decoder, the CEN64 dual-lookup decoder, and my perfect-hash-function-based decoder and see which is the most performant.

We need an RSP version of the mipsiii.json instruction database, so that we can use all the techniques we're developing for the VR4300 in our RSP implementation as well.

We need to emulate the Instruction Cache. It's fairly straightforward.