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
