> 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
