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
