Hi Gabe, I think this ties back to the parallel CC registers discussion on the dev list. I agree with the general goal of making the CPU models register agnostic. However, for renaming reasons, we need multiple pools of registers (effectively register types). Their representation should be opaque to most CPU models though (the KVM CPU being the big exception).
The main problem when switching to just using double/uint64_t for registers is that it breaks renaming for vector registers. In practice, you want to rename individual vector registers (NEON pre aarch64 and MMX(?) being an annoying exceptions). For something like Arm SVE, you are looking at up to 2048 bits per register. To support that efficiently, gem5's vector register APIs use references to the physical registers. It would be nice if could generalise this so that there is a way to specify how many register classes an architecture needs, the number of registers, and the size of the registers. The CPUs would then only need to deal with the tuple (type, idx) and pass pointers/references to the underlying registers. That would probably affect integer performance due to the additional indirection(s), so it might not work in practice. A pragmatic approach would be to have two types of register interfaces, one for registers that are up to 64 bits and one for large registers. In practice, that probably means unifying CC regs, scalar FP, miscregs, and integer registers. Cheers, Andreas On 13/10/2018 00:37, Gabe Black wrote: Boris: While that sounds similar and is an important fix to preserve, it's mostly unrelated to what we're talking about. What we're talking about are the types like X86ISA::IntReg, AlphaISA::MiscReg, etc. Andreas: I'm definitely of the opinion that the CPUs should work with abstracted registers which are just word addressed chunks of storage. I don't think they should (without a strongly compelling reason) know about meta types like SIMD registers, segment descriptors in x86, etc., and should instead consider them just a collection of blobs of data. I think before you talked about how renaming handled SIMD registers (maybe?), and that is something to consider. Renaming the individual bits of a wide register *might* be beneficial if there are dependencies on only part of a register, but that's probably pretty rare and may be unrealistic anyway. Then once you get a value back from the CPU, you can go nuts wrapping it in specialized types like BitUnions which make it way easier to access, etc., but without contaminating the CPU model with all that detail. You can also use whatever ISA specific local type you want, so if you want to work with a uint32_t for your integer registers (for instance in 32 bit x86), you can just assign to a smaller type and throw away the extra bits. I also wonder whether the compiler would be smart enough to realize the structs were really just ints, or if, for instance, the ABI would force it to put them on the stack and use a slightly less efficient interface when passing them around? Not sure, but something to consider. As far as x87 and 80 bit floating point, I personally made that concession a long time ago :-). I don't think many people care about x87 in general these days except if they just need to get something to run which happens to use it, and it's not likely the small differences using regular 64 bit FP would make any difference. Fortunately I don't think ISAs add any weirdly sized floating point support these days, they just make really big registers out of normal types. No promises on timeline since squishing ISAs together is largely something I'm doing for my own amusement at this point, but I'll try to get some CLs together along these lines. I don't think it will be anything very exciting since I think most things are already using the same types for registers anyway. Hopefully nothing will explode :-). Gabe On Fri, Oct 12, 2018 at 10:32 AM Andreas Sandberg <[email protected]<mailto:[email protected]>> wrote: Hi Gabe, I have been thinking along similar lines. I think I would prefer wrapping the registers in a struct and/or union to make the access size explicit. Floats are a bit annoying though since x86 would, ideally, need-80 bit registers. I think there might be a similar issue for integer registers once 128-bit RISCV ISA has been defined. The CPU models probably wouldn't need to worry about the contents of the structs though, so it should be possible to optimise at compile time if someone decides to only compile a subset of the ISAs. In general, I think this would be a good direction since it would make gem5 more modular. Cheers, Andreas On 12/10/2018 11:58, Gabe Black wrote:
Hi folks. I was digging around in gem5 today, and thinking about the ISA dependencies of the ThreadContext class. Some of those stem from the fact that many of the functions in that class are for accessing registers, and each ISA has different types defined for integer, floating point, and "misc" (control) registers. It seems to me that at least for the functions that access those registers, we could standardize on a generic type for all the ISAs. That would be similar to how the Addr type is the same for all ISAs, specifically a uint64_t. That type is sufficient for all the ISAs we support, although it may not always be necessary. Similarly, I think we could make the universal type for integer and control registers, a uint64_t, and floating point registers doubles. The actual type consumed by instructions could be down converted to something smaller if necessary with no loss of information. Thoughts? Gabe _______________________________________________ gem5-dev mailing list [email protected]<mailto:[email protected]> http://m5sim.org/mailman/listinfo/gem5-dev
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
