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
