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
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 thi
Hi Jasmin. There is some documentation, although it's not as complete as it
could be. I think you can find most of it on the gem5 website. ISA
generation is one of the more complex areas of gem5 (part of what I'm
hoping to improve), and is probably particularly hard to learn and
understand just fro
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 Santill
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
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
