[gem5-dev] Re: Add AVX512 Support?
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 于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: > >
[gem5-dev] Re: Add AVX512 Support?
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 Gabe Black via gem5-dev 于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 > 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
[gem5-dev] Re: ISA description structure
Hi Jasmin. There is some documentation, although it's not as complete as it could be. I think you can find most of it on the gem5 website. ISA generation is one of the more complex areas of gem5 (part of what I'm hoping to improve), and is probably particularly hard to learn and understand just from reading the documentation. If I dive into this at some point, I'm sure there's going to be some amount of porting necessary to move things from the existing system to a new one, and that would be a great way to help out. That wouldn't require quite as much deep knowledge of the current system, and there will be a lot of code to churn through at that stage. Thanks for volunteering to help out! Gabe On Sun, May 31, 2020 at 7:10 AM Jasmin Jahic via gem5-dev wrote: > Hello, > > is there some sort of documentation of the architecture of the whole > project? > > If no, I would be happy to help with this (is my research topic and have > experience with industry projects). > > Best regards, > > Jasmin JAHIC > > On 5/31/20 10:22 AM, Ciro Santilli via gem5-dev wrote: > > Gabe, I just want to say, I would be REALLY happy if those monolithic > files were split up somehow, to improve rebuild times and not crash my > debuggers/IDEs, if someone manages that it would be amazing. > > > > I was also thinking about the scons approach you mentioned, where we can > generate one .cc/.hh file for each .isa file separately, so that it would > be possible to know what you have to include to avoid having one huge > header definition inclusion. > > > > I also intend some day to try and reduce the usage of .isa in general, > because it is too insane/hard to learn/debug. The decoder part is already > basically pure C++ for ARM at least already, so a conversion would be > trivial. And I wonder how much we could get rid of with modern C++ template > features from the execute itself. > > > > From: Gabe Black via gem5-dev > > Sent: Sunday, May 31, 2020 4:23 AM > > To: gem5 Developer List > > Cc: Gabe Black > > Subject: [gem5-dev] ISA description structure > > > > Hi folks. This is just a quick email with some thoughts on the structure > of > > ISA descriptions in gem5, both to record my thinking thus far, and to > > encourage discussion. > > > > Right now, the structure of an ISA description flows from the > specification > > of the decode function. That takes an instruction blob, and then through > > nested switch statements travels down a decision tree to figure out what > > the instruction decodes to. At the leaf of the tree, the intention is > that > > an instruction is described inline when and where the decoder should > return > > that instruction. Exactly how that definition is interpreted depends on > > either an explicit "format" set for that instruction, or a global default > > format which is active for that region of the decoder. > > > > This is relatively straightforward, but makes a few assumptions which, > > while true for Alpha, are not universally true for all ISAs. > > > > 1. That an instruction only shows up in the decoder in one place. > > 2. That the decoding of an instruction can be expressed as a set of > nested > > switch statements based on bitfields (natural or synthetic) in the > > canonical ExtMachInst representation of the instruction as pulled from > > memory. > > > > This also doesn't scale very well when there are lots of instructions, or > > very complex instructions, or lots of very complex instructions, because > a > > lot of the guts of the instructions end up in the decoder itself, rather > > than pulled into other files. > > > > The decoder and instruction header and implementation files end up being > > HUGE monolithic files which create their own problems, slowing down > > linking, and even sometimes overwhelming compilers. > > > > > > One thing I'm thinking about is to pull the definition of the instruction > > objects out of the decoder itself, and to make them their own first class > > objects. I'm thinking something sort of like SimObjects which have a base > > class that handles a lot of the magic for them and sets up machinery for > > outputting .cc and .hh files and specifying how to return one from the > > decoder. These would then each generate a set of files which would > > implement just that instruction, and include the headers from any base > > class, again like SimObjects. > > > > Another idea I had more recently is that this could be done at the scons > > level, so that scons would be aware of all the instructions and the files > > they generate. This may have an impact on build time and so should be > > considered carefully. One option would be to tell scons where ISA files > > were like how Source() files are declared, and then have those do a > > pre-build but post-source-collection step where they run and expand into > > .cc and .hh files if they haven't changed. This would be somewhat like > how > > python files are turned into .cc files so
[gem5-dev] Re: ISA description structure
Yeah, the way the decoder itself is generated also needs to be revamped for exactly the reason you're describing, although I don't want to bite off too much at a time. I'm definitely aware of that issue though, and hope to get to it at some point. Gabe On Sun, May 31, 2020 at 1:23 AM Ciro Santilli wrote: > Gabe, I just want to say, I would be REALLY happy if those monolithic > files were split up somehow, to improve rebuild times and not crash my > debuggers/IDEs, if someone manages that it would be amazing. > > I was also thinking about the scons approach you mentioned, where we can > generate > one .cc/.hh file for each .isa file separately, so that it would be > possible to know what you have to include to avoid having one huge header > definition inclusion. > > I also intend some day to try and reduce the usage of .isa in general, > because it is too insane/hard to learn/debug. The decoder part is already > basically pure C++ for ARM at least already, so a conversion would be > trivial. And I wonder how much we could get rid of with modern C++ template > features from the execute itself. > -- > *From:* Gabe Black via gem5-dev > *Sent:* Sunday, May 31, 2020 4:23 AM > *To:* gem5 Developer List > *Cc:* Gabe Black > *Subject:* [gem5-dev] ISA description structure > > Hi folks. This is just a quick email with some thoughts on the structure of > ISA descriptions in gem5, both to record my thinking thus far, and to > encourage discussion. > > Right now, the structure of an ISA description flows from the specification > of the decode function. That takes an instruction blob, and then through > nested switch statements travels down a decision tree to figure out what > the instruction decodes to. At the leaf of the tree, the intention is that > an instruction is described inline when and where the decoder should return > that instruction. Exactly how that definition is interpreted depends on > either an explicit "format" set for that instruction, or a global default > format which is active for that region of the decoder. > > This is relatively straightforward, but makes a few assumptions which, > while true for Alpha, are not universally true for all ISAs. > > 1. That an instruction only shows up in the decoder in one place. > 2. That the decoding of an instruction can be expressed as a set of nested > switch statements based on bitfields (natural or synthetic) in the > canonical ExtMachInst representation of the instruction as pulled from > memory. > > This also doesn't scale very well when there are lots of instructions, or > very complex instructions, or lots of very complex instructions, because a > lot of the guts of the instructions end up in the decoder itself, rather > than pulled into other files. > > The decoder and instruction header and implementation files end up being > HUGE monolithic files which create their own problems, slowing down > linking, and even sometimes overwhelming compilers. > > > One thing I'm thinking about is to pull the definition of the instruction > objects out of the decoder itself, and to make them their own first class > objects. I'm thinking something sort of like SimObjects which have a base > class that handles a lot of the magic for them and sets up machinery for > outputting .cc and .hh files and specifying how to return one from the > decoder. These would then each generate a set of files which would > implement just that instruction, and include the headers from any base > class, again like SimObjects. > > Another idea I had more recently is that this could be done at the scons > level, so that scons would be aware of all the instructions and the files > they generate. This may have an impact on build time and so should be > considered carefully. One option would be to tell scons where ISA files > were like how Source() files are declared, and then have those do a > pre-build but post-source-collection step where they run and expand into > .cc and .hh files if they haven't changed. This would be somewhat like how > python files are turned into .cc files so they can be embedded into gem5. > > Thoughts? > Gabe > ___ > 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 > 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 -- 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] Re: Add AVX512 Support?
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 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 >
[gem5-dev] Add AVX512 Support?
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 ___ 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] Re: ISA description structure
Hello, is there some sort of documentation of the architecture of the whole project? If no, I would be happy to help with this (is my research topic and have experience with industry projects). Best regards, Jasmin JAHIC On 5/31/20 10:22 AM, Ciro Santilli via gem5-dev wrote: Gabe, I just want to say, I would be REALLY happy if those monolithic files were split up somehow, to improve rebuild times and not crash my debuggers/IDEs, if someone manages that it would be amazing. I was also thinking about the scons approach you mentioned, where we can generate one .cc/.hh file for each .isa file separately, so that it would be possible to know what you have to include to avoid having one huge header definition inclusion. I also intend some day to try and reduce the usage of .isa in general, because it is too insane/hard to learn/debug. The decoder part is already basically pure C++ for ARM at least already, so a conversion would be trivial. And I wonder how much we could get rid of with modern C++ template features from the execute itself. From: Gabe Black via gem5-dev Sent: Sunday, May 31, 2020 4:23 AM To: gem5 Developer List Cc: Gabe Black Subject: [gem5-dev] ISA description structure Hi folks. This is just a quick email with some thoughts on the structure of ISA descriptions in gem5, both to record my thinking thus far, and to encourage discussion. Right now, the structure of an ISA description flows from the specification of the decode function. That takes an instruction blob, and then through nested switch statements travels down a decision tree to figure out what the instruction decodes to. At the leaf of the tree, the intention is that an instruction is described inline when and where the decoder should return that instruction. Exactly how that definition is interpreted depends on either an explicit "format" set for that instruction, or a global default format which is active for that region of the decoder. This is relatively straightforward, but makes a few assumptions which, while true for Alpha, are not universally true for all ISAs. 1. That an instruction only shows up in the decoder in one place. 2. That the decoding of an instruction can be expressed as a set of nested switch statements based on bitfields (natural or synthetic) in the canonical ExtMachInst representation of the instruction as pulled from memory. This also doesn't scale very well when there are lots of instructions, or very complex instructions, or lots of very complex instructions, because a lot of the guts of the instructions end up in the decoder itself, rather than pulled into other files. The decoder and instruction header and implementation files end up being HUGE monolithic files which create their own problems, slowing down linking, and even sometimes overwhelming compilers. One thing I'm thinking about is to pull the definition of the instruction objects out of the decoder itself, and to make them their own first class objects. I'm thinking something sort of like SimObjects which have a base class that handles a lot of the magic for them and sets up machinery for outputting .cc and .hh files and specifying how to return one from the decoder. These would then each generate a set of files which would implement just that instruction, and include the headers from any base class, again like SimObjects. Another idea I had more recently is that this could be done at the scons level, so that scons would be aware of all the instructions and the files they generate. This may have an impact on build time and so should be considered carefully. One option would be to tell scons where ISA files were like how Source() files are declared, and then have those do a pre-build but post-source-collection step where they run and expand into .cc and .hh files if they haven't changed. This would be somewhat like how python files are turned into .cc files so they can be embedded into gem5. Thoughts? Gabe ___ 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] Re: ISA description structure
Gabe, I just want to say, I would be REALLY happy if those monolithic files were split up somehow, to improve rebuild times and not crash my debuggers/IDEs, if someone manages that it would be amazing. I was also thinking about the scons approach you mentioned, where we can generate one .cc/.hh file for each .isa file separately, so that it would be possible to know what you have to include to avoid having one huge header definition inclusion. I also intend some day to try and reduce the usage of .isa in general, because it is too insane/hard to learn/debug. The decoder part is already basically pure C++ for ARM at least already, so a conversion would be trivial. And I wonder how much we could get rid of with modern C++ template features from the execute itself. From: Gabe Black via gem5-dev Sent: Sunday, May 31, 2020 4:23 AM To: gem5 Developer List Cc: Gabe Black Subject: [gem5-dev] ISA description structure Hi folks. This is just a quick email with some thoughts on the structure of ISA descriptions in gem5, both to record my thinking thus far, and to encourage discussion. Right now, the structure of an ISA description flows from the specification of the decode function. That takes an instruction blob, and then through nested switch statements travels down a decision tree to figure out what the instruction decodes to. At the leaf of the tree, the intention is that an instruction is described inline when and where the decoder should return that instruction. Exactly how that definition is interpreted depends on either an explicit "format" set for that instruction, or a global default format which is active for that region of the decoder. This is relatively straightforward, but makes a few assumptions which, while true for Alpha, are not universally true for all ISAs. 1. That an instruction only shows up in the decoder in one place. 2. That the decoding of an instruction can be expressed as a set of nested switch statements based on bitfields (natural or synthetic) in the canonical ExtMachInst representation of the instruction as pulled from memory. This also doesn't scale very well when there are lots of instructions, or very complex instructions, or lots of very complex instructions, because a lot of the guts of the instructions end up in the decoder itself, rather than pulled into other files. The decoder and instruction header and implementation files end up being HUGE monolithic files which create their own problems, slowing down linking, and even sometimes overwhelming compilers. One thing I'm thinking about is to pull the definition of the instruction objects out of the decoder itself, and to make them their own first class objects. I'm thinking something sort of like SimObjects which have a base class that handles a lot of the magic for them and sets up machinery for outputting .cc and .hh files and specifying how to return one from the decoder. These would then each generate a set of files which would implement just that instruction, and include the headers from any base class, again like SimObjects. Another idea I had more recently is that this could be done at the scons level, so that scons would be aware of all the instructions and the files they generate. This may have an impact on build time and so should be considered carefully. One option would be to tell scons where ISA files were like how Source() files are declared, and then have those do a pre-build but post-source-collection step where they run and expand into .cc and .hh files if they haven't changed. This would be somewhat like how python files are turned into .cc files so they can be embedded into gem5. Thoughts? Gabe ___ 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
