>> 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'm wondering the same thing... I agree, it would be sort of nice to have > everything in one binary (or at least have that option), but is it that big > of a practical gain? And wouldn't having that many more source files just > increase the scons overhead further (independent of the SLICC parsing > times)? I guess it depends on how you define "a lot". Is it an hour? no. Is it a month? no. It would not increase scons overhead since you'd be compiling all of the ruby files the same number of times. What it will save is recompiling a bazillion non-ruby files just to compile in the different protocols. Wouldn't it suck if we had to compile a different version of gem5 for each CPU model? The problem is that we're now at the point where we have a ton of different configurations that need to be compiled and our "quick" regressions take forever because compiling takes forever. We're also only trying out the different protocols with Alpha. Seems to me that we need to try more of a crossproduct. Maybe things like endianness screw us up? Maybe atomic operations screw us up. Simply put, some effort here will reduce our development overhead and compile time (and carbon footprint) significantly. When I work on stuff like python stats, I end up getting bogged down in compilation and it's not because scons is taking a long time to read everything (though that takes longer than it would if we had fewer builds).
> It seems like we've got the original se.py problem solved (correct?), so > it's not like there's a bug that really needs this capability to be fixed. I actually see this as unrelated. Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
