Quoting nathan binkert <[email protected]>:
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).
I agree.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
