On Sat, Jul 10, 2010 at 3:11 PM, Gabe Black <gbl...@eecs.umich.edu> wrote: > I'm replying on m5-dev instead of review board since this is wandering > away from the topic of Timothy's code. Please let me know if we're > trying to keep things on there anyway.
No, I think you made the right move. > I've thought before that it would be nice to have generic versions of > utility and other functionality as well. A class is nice because you can > use inheritance with all of its benefits, but you can't add to a class > once it's defined and that can be a real pain. That's why, way back, I > went and moved everything from ISA classes into ISA namespaces (That was > me, wasn't it? How can I forget these details?). What I think would work > and is similar to what I've seen in some other projects is to have a > "generic" isa directory and a GenericISA namespace. In that we'd put all > the common versions of things (or even multiple versions, if there's > more than one common case) and the normal ISAs would be able to either > wrap them or add "using GenericISA::foo" to their namespace to pull > those in. That complicates building a tiny bit since the GenericISA > always needs to be built in and isn't really an ISA (maybe we just treat > it like a source directory?) but I think it mostly solves the problem. That sounds like a good plan to me. > As far as process initialization, that does need to be worked on. I was > alluding to that in my other email in the thread about the > initialization stuff. I think this might benefit from providing utility > functions/utility classes/base class methods that do smaller parts of > the initialization and then mix/match/replace those in the ISA classes. > It would be too messy, I think, to try to parameterize everything that > might change, and too complicated to add hooks in the base class methods > everywhere someone might want to override something. We could, though, > provide a generic version of the function that strings together the > components in a sensible way, if nothing else to provide a baseline for > someone implementing a new ISA. Or, if there no new ISA's we care about > still to implement (?), a new OS. I doubt there's a one-size-fits-all solution... in some cases you may want parameters, in others you may want function hooks, and other cases may be handled best with templates. Not that we want to create an inconsistent mess, but we shouldn't feel like we need everything to look the same either. That is, you do want a single underlying mechanism (like the GenericISA namespace) but within that you could have base classes with virtual methods, templated functions, parameterized functions, etc. The main thing, like I said before, is that if the default function is 90% of what you need, you should find a way to add in the flexibility to get that last 10% without copying and pasting the 90% that doesn't change. Sadly a lot of this has already been done, but let's at least try and avoid making it any worse. I think the other key thing is that you want to put the flexibility where you actually need it, and not spend a lot of time designing in flexibility that you don't need yet just because you think you might someday. (I'm sure many of you have heard that theme from me before.) In particular, now that we have a pretty broad range of ISAs implemented, it's unlikely we'll find a new dimension where we need some flexibility that we haven't needed yet. > Also, this makes me think of the isa_parser. I know that dead horse > probably looks like mashed potatoes by now, but I think it would be > better to provide that functionality as a python library with a > collection of generic classes and whatnot, and then for each ISA to use > those or extend them as necessary. The alternatives are, I think, to > either make the parser handle every quirk of every ISA, or to provide > hooks to override all of its functionality anyway. Otherwise you (or > really I) end up with things like the x86 implementation which use the > parser but have to do a lot of extra work to subvert it in some cases. I > think if we take the same functionality but wrap it in components that > can be picked and chosen from and/or specialized and then combined into > a whole, things will be cleaner and easier than making one more > monolithic system that needs to be broken apart and then layered over > and/or specialized after the fact. Yea, we'll have to sit down and seriously figure this out someday. I certainly agree that the status quo, while effective, is not particularly pretty. I'm reluctant to say we should go all the way to a library-based implementation, since I still think there's something to be gained from having a more concise syntax that's specialized to the problem at hand, but it would be fun to look at how we'd do it now that we have all this experience under our belts. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
