Hi Gabe, Thanks for your reply. For the vector register file, I agree it is probably a better idea to stick with current approach, at least it does not require changing the SSE instructions. I cound not find your plan to redesign the register handling mechanism. If you could provide a link I would be interested to take a look to have better understanding of the philosophy behind the design.
Let's hear from AMD first as they have more insights about the microop. If everything turns out well, I can start to refactor the code into smaller commits and add tests for that. *王 钲 荣* Zhengrong Wang Computer Science Department University of California, Los Angeles California, USA 90024 Work Email: [email protected] Mobile :+1 310-447-4568 Gabe Black via gem5-dev <[email protected]> 于2020年5月31日周日 下午7:44写道： > Hi Sean. I'm not aware of anyone working on AVX-512, but it would be nice > if the AMD folks could chime in and confirm that. The x86 microcode was > originally based off of the microcode for the K6 as described in a patent. > The floating point parts of that patent were very vague and hand wavy, so I > more or less made up the initial part. It would be nice for the AMD folks > to chime in here too, as far as what's realistic for the design of the > microops. > > As far as testing, we don't have a great scheme for testing individual > instructions right now, but that would be really valuable to have in the > long run. I've thought a bit about how that might work, but I don't have a > plan at the moment. The best thing to do right now is to probably to have > small programs that execute the instructions in question and print their > inputs/outputs and/or check that the outputs are correct. I think our > testing framework has a way to check that program output matches a golden > reference, and that could be used to delegate correctness checking to the > framework. Bobby can probably give more details here. > > As far as the registers, my preference for now is to do what you did and > treat each 64 bit chunk as its own register. There are real drawbacks to > this approach, but the existing solution to them, a vector register file, > has other, in my opinion more serious, drawbacks. A while ago I put > together a manifesto about how I'd want to redo the whole register handling > mechanism in gem5, but unfortunately I haven't had time to actually > implement very much of it. By treating larger registers as groups of > smaller registers, you'd be consistent with the rest of the x86 code as it > stands right now. That, and the fact that I think that's the lesser of two > evils, makes that my preferred way to go. > > As far as submitting code, there are instructions on the gem5 website for > creating and submitting reviews. We use gerrit, and so in addition to the > instructions we provide, you should be able to find pretty good/complete > instructions out on the internet to explain the mechanism of sending out a > review. For this or any other change, you'd want to break up your work into > logical chunks where everything works before and after any given change, > and then send them out (perhaps all together in a series) for review. > Exactly how to break things up is up to you, but my opinion is that each > change should be logically complete but also about one thing. That makes it > easier for a reviewer to wrap their head around what you're doing and how > it works without having to untangle multiple things going on at once, or > having to merge multiple reviews together in their head to see the whole > change their reviewing. If there are lots of related small changes (many > individual instructions for instance) it might make sense to do one or two > by themselves first, and then once the kinks are worked out to do a larger > change with the rest, applying the pattern from the earlier reviews. > > Gabe > > On Sun, May 31, 2020 at 4:18 PM Sean Wong via gem5-dev <[email protected]> > wrote: > > > Hello, > > > > This is my first time posting here, so apologies if I made any mistakes. > > > > The last time I checked the develop branch, gem5 has not yet supported > the > > AVX512. And searching the mail list I do not see any plan for that. Is > > there any ongoing development to support that? If not, I am happy to > > contribute my code. During my research, I have developed partial support > > for AVX512 (and AVX-256 as a by-product), which I hope would be useful > for > > others. > > > > My implementation so far is a straightforward extension to the existing > SSE > > instructions. To summarize it: > > > > - Like SSE implementation, the 512-bit register is broken into 8 64-bit > > sub-register. This may not be a good design. Any suggestions are welcome. > > - Unlike SSE implementation, most of the instructions are broken into a > > single microop. For example, a 512-bit 'vaddps' is decoded into one > 'vaddf' > > microop instead of eight. > > - Currently, it supports common arithmetic instructions (add, mul, etc.) > > and basic data movement (load, store, mov, extract, insert, etc.). > > - No support for masking. > > > > If you guys are interested, I am willing to clean my code and submit for > > review. I may need some guidance on: > > > > - Design of the vector register file. My implementation directly follows > > the SSE instructions to minimize the work. Is there any better way to do > > this? > > - If I am going to merge my code, what is a good submission plan? I am > > thinking about first committing the skeleton code with a simple 'vaddps' > > instruction, and then for other instructions. > > - Testing: This is probably the most important one. Currently, I manually > > test my code by simulating small programs. What is the best way to write > > tests for new instructions? Should I try unit testing for binary testing? > > > > Thank you for reading this long post. Any feedback is welcome. > > > > *王 钲 荣* > > > > Zhengrong Wang > > Computer Science Department > > University of California, Los Angeles > > California, USA > > 90024 > > > > Work Email: [email protected] > > Mobile :+1 310-447-4568 <(310)%20447-4568> > > _______________________________________________ > > gem5-dev mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
