This is sort of what we have already for the PC, but I don't think exactly that would work for registers since they have to have more indirection for register flattening (an ISA level remapping for, for instance, register windows) and renaming in CPUs like O3. Something like this in spirit might work though, although I haven't thought about it enough to really get a good idea of how. It would also be nice to avoid virtual functions since those have some overhead, but there's bound to be some amount of indirection somewhere. We would just want to minimize the number of trips we have to take through a function pointer vs. a direct function call.
Gabe On Sun, Oct 21, 2018 at 9:10 AM Alec Roelke <[email protected]> wrote: > 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 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
