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]> 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] > > 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. > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
