https://docs.google.com/document/d/1O_u_Xq14TgreYThuZcbM3kuXFCrKvaFHA2O9poCeHSk/edit#heading=h.r067bn3rmydo
On Sun, May 31, 2020 at 9:31 PM Zhengrong Wang via gem5-dev < gem5-dev@gem5.org> wrote: > 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: seanyukig...@gmail.com > Mobile :+1 310-447-4568 <(310)%20447-4568> > > > > > Gabe Black via gem5-dev <gem5-dev@gem5.org> 于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 < > gem5-dev@gem5.org> > > 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: seanyukig...@gmail.com > > > Mobile :+1 310-447-4568 <(310)%20447-4568> <(310)%20447-4568> > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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 > _______________________________________________ > 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 _______________________________________________ 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
