Hi all, In working to integrate the RISC-V vector instructions (RVV) implementation from Rivos, I've come across a unique (to me) problem. In RVV, the vector length and the size of the vector element is specified *at runtime* by the `setvl` instruction. So, the way you decode a vector instruction changes depending on the previous instructions that have executed.
The problem is that when constructing a static instruction, you need to know the number of source and destination registers. You also need to be able to set the src/dest register ids (though, I have to be honest that I don't fully understand what `set[Src/Dest]RegIdx` is actually doing). However, for RISC-V vector instructions, the number of src/dest registers and register IDs depends on the current state (execution context). The vector length, masking, and vector element size is dependent on `MISCREG_VL` and `MISCREG_VTYPE`. Right now, these are MISCREGs, but it may be more appropriate to use a different register class (e.g., something more like CC regs?). I can't find another example of this kind of dependency in the codebase. If someone could point me to an example of how to use execution context state to decode, I would appreciate it. I have a feeling this is a new requirement. So, assuming there's no good examples today, I'd appreciate some pointers for the "right" way to implement this. Right now, I'm not very concerned with being able to rename these registers. Getting RVV working for the O3CPU isn't a requirement currently. If we can come up with a solution that works in the simple case first, then try to generalize to O3, that would be good with me. I suppose one option would be to use the thread context (not execution context) in the decoder to "speculate" what the vector length is, then, in execute, read the correct value and make sure we're correct. This may work for the Simple CPU. It probably won't work for the other CPU models. Here's a link to the current (working) implementation that "hacks" around the issue by passing the MISCREGs into the decoder. https://github.com/rivosinc/gem5/commit/d6d068c9fabf34e5327107513ec41dea3e5e9acc We could instead use the thread context pointer in the ISA object, but I don't believe that will solve the problem generally. Thanks for the input! Cheers, Jason
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
