On Wed, Feb 24, 2021 at 8:05 AM Giacomo Travaglini < [email protected]> wrote:
> > > > -----Original Message----- > > From: Gabe Black <[email protected]> > > Sent: 24 February 2021 15:24 > > To: Giacomo Travaglini <[email protected]> > > Cc: gem5 Developer List <[email protected]> > > Subject: Re: [gem5-dev] vector register indexing modes and renaming? > > > > 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. > > I will ask within Arm if there's something we can provide to you. > In the meantime I gave a quick look at NEON enabled libraries [1]; the > Ne10 library provides a set of functions optimized for NEON and a set > of examples making use of it [2] (e.g FIR filter, GEMM etc etc). > > You could probably cross-compile those examples and use them in SE mode > (recommending to use the O3 model) > Ok, thanks, I'll take a look. This might even be something we want in the testing infrastructure? I might look into that when I have a chance. > > > 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 > > > > I have the hunch the vector lane logic it's not really used. > My understanding is that Lane/Elem differ in the O3 model only. > The key point is that VecRegister and VecElems are represented by a > different set of physical registers; you cannot access a vector element if > the renaming is set to Full[3]; the physical vector register file will be > made of valid entries, while the vector element register file will be > empty. The vector lane getters/setters are probably a way to do a > functional read of the element anyway [4]. > In a way we could think of VecReg/VecElem as being the interface to the > vector file for a guest instruction, while the VecLane to be the interface > for the host (even though it could be used by an instruction as well) > > This is my interpretation of the VecLane > Ok, thanks. If there are things we can eliminate from the interfaces then that will make the whole problem simpler. Part of what makes this hard to work on are that there are so many things that need to move in parallel to keep everything working (whole registers, elements, lanes, ThreadContext, ExecContext, SimpleThread, dynamic inst classes, O3 register file and rename map, minor CPU and O3 scoreboard, parser implementation, operand definitions, instruction definitions). Finding a place to unravel a small part of this at a time has been tricky... Gabe
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
