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
