Thanks for the CRTP description. Using CRTP makes sense from a performance perspective. Since the "this" pointer isn't what we need, it seems like CRTP only makes sense for the MachineType other isolated situations. Most of the classes generated by SLICC will have to append the protocol name to the object.
Overall this seems like a lot of work. So what is the benefit? It is just reducing the number of binaries the regression tester needs to compile? I do remember your previous analysis of the SLICC parsing performance and I do believe you. It would be great we could reduce or remove the unnecessary work being done by scons with the generated SLICC files (dependency graph analysis, etc.). I think the reason that this issue keeps coming up, is that gem5 scons-SLICC takes much longer to rebuild simple changes than GEMS make-SLICC. For those of who remember the old infrastructure, that is one area that we miss. However, please don't take my comment the wrong way. gem5 does improve on GEMS in many, many, many other ways. Brad > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of nathan binkert > Sent: Thursday, July 21, 2011 9:47 AM > To: gem5 Developer List > Subject: Re: [gem5-dev] se.py > > > Can you explain a little bit of what you have in mind? I suspect > that we can append many functions and class names with the protocol > name to disambiguate. However, dealing with multiple definitions of > MachineType and its associated helper functions will be nontrivial. I > suppose we could move all that functionality to an abstract class, but > that may have some unforeseen consequences...not impossible though. > > The correct way to do this is using templates and the CRTP > (http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern) or > using templates and policies. CRTP tends to be easier, but policies > have some benefits. CRTP is kinda like compile time virtual > functions. Policies are more like filling in missing functions using > template parameters. The benefit of using policies is that it is > clearer what is missing from the base class. The downside is that you > don't really have a "this" pointer that does what you want. > > Basically the situation is this: the src/mem/ruby directory contains > many classes whose definitions are not complete in that some of their > functions aren't there and must be generated by slicc. If we treat > these as a templated base class and use the CRTP/policies to get to > the missing parts, then it should be easy to define a set of classes > for each protocol. > > In the past we might have had something like the situation where a > function foo() was in the common set of things and the function bar() > was generated by slicc. When foo() calls bar(), foo needs to know > which protocol it is working with. You'd usually use virtual > functions with this, but that is slow and the alternative is > CRTP/Policies. > > While a "set of classes for each protocol" may sounds like a perfect > use of namespaces namespaces, the "incomplete" class issue makes it > fall down. This is because there is a lot of common code that needs > to be duplicated across the protocols (because the common code needs > to call into the protocol specific code) and there's no clean way to > do that with namespaces. > > > So if we make such a change, would scons need to parse all the .sm > files at the beginning of compilation? Is there a way to avoid that? > Yes. But it would only be for those protocols that you specify and > again, this takes next to no time at all. I think I published numbers > about how this is way less than one second of CPU time. I think the > reason that people think ruby took so long was that it's text was spit > out on the screen and there was a wait before you saw the next thing, > but in that wait, almost none of the time was SLICC, but rather just > stuff that didn't print to the screen (like building the dependency > graph). If you like, we can put a "slicc start parse...." and then > print "end" when it is done, but to be honest, I think you guys just > need to take my word for it that this is not a performance issue > (there are many with our build system, but this isn't one of them.) > > Nate > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
