Yeah, I don't think it would even be feasible to change the current setup in a major way without starting over with the ISA implementations. I want to figure out incremental steps to improve things without throwing out the baby with the bathwater as far as what the current system gives us, and the existing implementations on top of it. It's certainly better than macros, although I think pretty much anything would be :-) Some high level goals I can think of are:
1. Split up the output. 2. Make defining other types of decoders/decoder subtrees easier, without having to shoe horn them in using, for instance, one off instruction formats. 3. Collapsing some of the layers. On x86 we have scons->ISA parser->let blocks-> python code->microcode assembler->python customization->microcode definitions->python classes->c++. 4. Make unit testing instructions more feasible. A stretch goal would be to use something like LLVM to compile the snippets which define instruction behavior. That would let us more definitively do things like identify source/destination registers, count them, etc. Also, we could keep the IR around and use a JIT to have our own binary translation which would be behaviorally identical to the normal CPUs (for better or worse). There might be other things worth doing which I'm not thinking of at the moment, but I think there's plenty here at least to start with. Gabe On Mon, Jun 1, 2020 at 11:48 AM Steve Reinhardt via gem5-dev < gem5-dev@gem5.org> wrote: > 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 > _______________________________________________ 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
