So, I started really diving into the interfaces in ThreadContext and ExecContext and their various implementations. What I wanted to do was to define a much narrower set of maybe 3 virtual functions that actually implements the core of what's needed, and not 15-20 different independent virtual methods that all need to be reimplemented every time. *That* was quite the rabbit hole, and after a number of hours I decided I needed to regroup and come at it from another angle. It definitely looks to me like somebody came in with the idea to represent these registers using a data, model, view architecture (or something like that) which would make sense in other contexts with other types of data, but here I don't think is really the right way to go about this.
Right now, I have two questions for you. 1. Are there tests which exercise this stuff? If I start chopping things up, I would be a lot more comfortable if I can tell if/when I break something. 2. What's the difference between a lane and an element? Those terms seem like they should be synonyms and are treated as almost the same thing, but there is clearly a difference between them. What is it, and why does it exist? Gabe On Tue, Feb 23, 2021 at 4:21 AM Gabe Black <gabe.bl...@gmail.com> wrote: > That said, the first would avoid adding another register file while that > would still mean plumbing new interfaces all over the place for all the > ThreadContext and ExecContexts, etc. Once all that code is generic and you > can add or remove register files willy-nilly, it might make sense to switch > to the second option. > > Gabe > > On Tue, Feb 23, 2021 at 4:15 AM Gabe Black <gabe.bl...@gmail.com> wrote: > >> >>> > Hey ARM folks. Could someone please explain to me what the deal is >>> with the >>> > vector registers and renaming modes? What is fundamentally going on >>> there? >>> > My best guess is that the granularity that the registers are being >>> renamed at >>> > changes between the modes, or in other words you index by and rename by >>> > entire registers in one mode, and in the other mode you index by and >>> rename >>> > by just the "elements" within the registers? >>> >>> Yes that is correct, let me know if you need further info on this >>> >>> >>> >> Focusing just on this part for now (not to dismiss the other part), this >> brings me back to an idea in a proposal I sent out a while ago (you >> commented on it, I think) where there are "normal" register files for >> integers, etc, which use uint64_ts as entries, and then register files >> which are for other things which are opaque blobs. Those later register >> files would be basically an array of bytes with an index scaled by some >> arbitrary value and sized based on the scale and some register count. The >> "registers" would be passed around by pointer and cast/copied locally so >> the accessors can be generic. It sounds like the effect of changing between >> element/register indexing could be generically implemented by making it >> possible to reset the scale value for those register files. Another option >> would be to have two different register files, and then just copy things >> over to update the new one when switching. That would make the register >> files themselves simpler, and you have to do something kind of like that >> anyway to make the elements contiguous when switching from element indexing >> to register indexing. Which do you think makes more sense? I'm feeling like >> the second option makes the most sense since it would be easier to >> implement on the CPU side and would push the part that cares about indexing >> semantics and what maps equivalently to what into the thing doing the >> switch which is (presumably) already ISA specific. >> >> Gabe >> >> Gabe >> >
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
