Hi Everyone, The patches below have been on RB for a bit more than a week now. I¹m planning to commit them together with the serialization patches to make sure that all core API changes happen around the same time. This should hopefully reduce everyone¹s merge pain.
My current timeline is to submit them on Friday next week (26th June). I know that a lot of us are attending ISCA at the moment, so I¹m more than happy to wait if you want more time to review the patches. Thanks, Andreas On 08/06/2015 14:23, "Andreas Sandberg" <[email protected]> wrote: >Hi Everyone, > >I have had a patch to refactor serialization (RB2861 [1]) on review >board for a about a week and a half now. This patch is ready to go and >I'd like to push it this week. > >In addition to the serialization patches, there is a series of patches >to refactor draining: > >[2] python: Remove redundant drain when changing memory modes >[3] sim: Make the drain state a global typed enum >[4] sim: Move mem(Writeback|Invalidate) to SimObject >[5] sim: Decouple draining from the SimObject hierarchy >[6] sim: Refactor and simplify the drain API > >The main point of these changes is to reduce the amount of boiler plate >code and make draining more robust. By making the Drainable base class >and the DrainManager keep track of which objects need draining, we >remove the need for SimObjects to keep track of non-SimObjects that need >draining (e.g., devices that need to drain ports). This removes a lot of >boiler plate and the need to return other drain counts than 0 or 1. > >The logical extension to this is to make drain() return a DrainState [6] >and move all drain state handling to the base class. Previously, objects >were responsible for updating their own state, which often didn't >happen. This meant that we couldn't use the drain state as a reliable >way of telling what was going on in the system while it was draining. By >doing state transitions in the base class (Drainable), we now enforce >correct transitions. This also means that we can check that the system >is in the state we expect while draining. > >Being able to automatically detect if a system is drained means that >there is no long a need to explicitly resume drained systems (this is >done automatically in simulate() if needed) and calls drain() become >no-ops if the simulator is drained. > >All in all, the two last patches net -542 lines of (mostly) boiler plate >code. > >//Andreas > >[1] http://reviews.gem5.org/r/2861/ >[2] http://reviews.gem5.org/r/2871/ >[3] http://reviews.gem5.org/r/2872/ >[4] http://reviews.gem5.org/r/2873/ >[5] http://reviews.gem5.org/r/2874/ >[6] http://reviews.gem5.org/r/2875/ > > >-- IMPORTANT NOTICE: The contents of this email and any attachments are >confidential and may also be privileged. If you are not the intended >recipient, please notify the sender immediately and do not disclose the >contents to any other person, use it for any purpose, or store or copy >the information in any medium. Thank you. > >ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2557590 >ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2548782 > >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
