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 <ciro.santi...@arm.com> 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 <gem5-dev@gem5.org> > *Sent:* Sunday, May 31, 2020 4:23 AM > *To:* gem5 Developer List <gem5-dev@gem5.org> > *Cc:* Gabe Black <gabebl...@google.com> > *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
