The original ISA description language has certainly been extended/leveraged way beyond what it was originally designed for. It was written to replace the SimpleScalar Alpha decode logic which was based on cpp macros (!) so it was a big advance at the time, but given the expanded scope of doing things like x86 decode and microcode, a redesign seems reasonable.
That said: 1. If it's just a matter of shrinking the massive monolithic C++ output, that should be doable without extensive changes. I don't know what happened to it, but I recall working on this back at AMD. IIRC we had at least some preliminary ideas and had done some initial experimentation. 2. All an ISA decoder really needs to do is provide a StaticInst class hierarchy and a decode function; there's nothing that requires the use of the ISA description language, or requires all the ISAs to use the same approach. (At least that's how it's supposed to be.) So if the only/main problem with the more RISCy ISAs is splitting the output, that could be addressed separately as above, and a different approach could be used for x86, for example. Just a thought to maybe open up some additional options. Steve On Sun, May 31, 2020 at 7:10 AM Jasmin Jahic via gem5-dev <gem5-dev@gem5.org> 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 <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 > > _______________________________________________ > > 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
