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 <[email protected]> Sent: Sunday, May 31, 2020 4:23 AM To: gem5 Developer List <[email protected]> Cc: Gabe Black <[email protected]> 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 -- [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
