Of course, absolutely. I've been holding off sending them out for review because I fully expect they will need to change after Derek checks in his changes. However, I understand many are curious to see them and I would like to check them in before Christmas, so I'll go ahead and send them out now for review.
There are several near-term items listed below that these patches don't cover, but still need to be addressed. There are probably even more that what is listed. I'm hoping do complete the first 2-3 of these next week. We need a way to test libruby before we can clean-up Ruby's System.hh API. Maybe this task is better done by someone at Wisconsin? Brad Near-term To Do: 1. Resurrect and Test Ruby Cache and Trace Recording - For those that are unfamiliar, ruby warms up its caches by creating a trace during checkpoint creation and then running that trace through when a checkpoint is loaded. - I made a few small changes to this code so that it would build, but there it still needs to be tested. Also there is an obvious performance enhancement to make. 2. Memory Controller Profiler - As I mentioned in an email last week, I would like to move all the memory controller profiling code to a separate profiler object similar to the cache profiler - As a part of this item, make sure that all profiler objects print there stats - Currently the CacheProfiler does not print its stats 3. Support mapping functions - Define a system hierarchy in the python configuration that automatically generates mapping functions that can be used by the .sm files. - Subsequently this would remove the current 4. Clean up Ruby's System.hh API - Remove the "get" functions 5. Update regression tester - Steve recent told me that Nate has some updates to clean up the regression tester and not have it require a separate set of configuration files. - It would be great if we got ruby fs mode and all currently supported protocols into the regression tester - I would like to update the regression tester before we convert MessageBuffer to M5 style events 6. Convert to M5 style events - The patches I will send out will wrap M5 events as ruby events, however these M5 events will delete after they are used - We should convert Ruby to conserve events and map one event per ruby object - However, this change will require non-trivial changes to Ruby's MessageBuffer - If it is done correctly, we should not notice any changes in timing after the conversion and I would like to have the regression tester more thoroughly test ruby to make sure that is the case. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of nathan binkert Sent: Thursday, December 10, 2009 8:12 PM To: M5 Developer List Subject: Re: [m5-dev] Merging > Do you need any more help merging your outstanding changes? I'm almost > ready to check in my changes that unify configuration and the > eventqueue. However, I want to give you the opportunity to check in > your changes first. I hope that everyone with all of these big changes is planning to share them before they actually check them in. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
