Would it be reasonable to create an interface (or whatever C++'s equivalent is; I think just a class with only pure virtual methods) that defines a register and then have different modules that have registers implement it? Then the CPU would just work on instances of that interface, leaving the actual behavior when a read or a write takes place to the ISA or other module that uses it, and it won't need any references to ISAs like X86ISA::IntReg and so on. If enough ISAs have the same behaviors for registers, then this interface could include a default implementation as well.
On Thu, Oct 18, 2018 at 6:33 PM Gabe Black <[email protected]> wrote: > Yes, I agree. I think there are these axis when accessing a register. > > 1. Read vs. write > 2. Int vs. Float vs blob > 3. Side effects vs no > > What we have right now are a few instances with an appropriate collection > of properties for those instances, but it would be nice if we could make it > less one size fits all. > > Perhaps the blob type could work with a pointer or reference instead of an > actual value, and have a base type which is an empty struct? Not sure > exactly how that would work and still be mostly ISA independent, but > something along those lines so at least the interface doesn't have to be > specialized per ISA. > > Gabe > > On Thu, Oct 18, 2018 at 6:36 AM Andreas Sandberg <[email protected] > > > wrote: > > > 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]> 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. > >> > > > > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
