Hi Rekai, I too would love to see someone knowledgeable in other architectures, especially x86, take a look at these patches. Unfortunately, I'm not sure who we have around that either has the knowledge to do this, or has the time.
I'll take a stab at it soon, though I don't know much about the ISA parser or x86 implementation. But I'll try to provide any feedback I can. Thanks for the contribution! Jason On Mon, Jan 16, 2017 at 8:53 AM Rekai Gonzalez Alberquilla < [email protected]> wrote: > Hello again, > I have gone through a round of review of the patches I submitted before > Christmas, as in the rebasing I missed a couple things that made some > regressions fail, and they were also some style mistakes. The patches > concerned are: 3754, 3756, 3757, 3758 and 3760. > I would really appreciate it if someone knowledgeable about the arch > modeling, specially someone knowledgeable on non-ARM architectures, could > spare some time to take a look for wrong assumptions or shortcomings, in > the code. > Cheers, > Rekai > > PS: Links to ease the navigation: > http://reviews.gem5.org/r/3754/ > http://reviews.gem5.org/r/3756/ > http://reviews.gem5.org/r/3757/ > http://reviews.gem5.org/r/3758/ > http://reviews.gem5.org/r/3760/ > > > > From: Rekai Gonzalez Alberquilla > Sent: 10 December 2016 15:46 > To: [email protected] > Subject: Vector register file > > > Hi folks, > > Yesterday I submitted five patches to the review board. The idea of the > patches is to implement a proper vector register file. To enable cleaner > implementations of the SIMD ISAs. > > > > The first patch extends what Nathanael Premillieu did in spring, taking > the hierarchical RegIds, and generalising the usage of them. > > > > The second patch is an 'enabler'. It is a refactorisation of the > InstResult, as having Vector Regs, and being able to define operations that > operate on a vector register, we need to contemplate the possibility of > instructions generating vector results. There are a couple points in the > code that require bearing in mind that this change is right before adding > vector registers to make sense. > > > > The third patch adds the vector register class. For the implementation we > decided to decouple the uarch entity that is the register, codified in the > VecRegContainer class, which is just a group of bytes, from the > interpretation of it, which belongs to the arch world. To do that, > VecRegContainers have methods to create a view of the bytes as a vector of > any plain type. This views, VecRegT have the expected functionality to > inspect and modify the contents of the register. > > > > The fourth patch (cpu: Added interface for vector reg file) creates a > vector register file in the cpu models, and adds all the interface > functions required across classes that implement ThreadContext or > ExecContext interfaces. The rename is extended. Due to the particularities > of some ISAs, the same set of registers can be accessed at register level, > or at 'native element' level. Therefore, the rename stage and the rename > map are updated in this patch to address that need. One particularly odd > piece of functionality is a function to change the mode, as different > 'chunks' may need to be consolidated into one physical vector register to > preserve ISA semantics. > > > > Finally, the last patch proposes updates to the parsing of the operands in > Neon instructions for ARM to use the newly added Vector Register file. > > > > Cheers, > > Rekai > > 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 > -- Jason _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
