> > > > 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
