Searched hist:13144 (Results 1 - 4 of 4) sorted by relevance
| /gem5/src/cpu/simple/ | ||
| H A D | noncaching.hh | 13113:687a2b956f7b Mon Oct 01 09:07:00 EDT 2018 Giacomo Travaglini <giacomo.travaglini@arm.com> cpu: Fix typo in header guard for Noncaching cpu Change-Id: If8ec5f5f49e99d4989658273723b943dd8df84c6 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/13144 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/systemc/core/ | ||
| H A D | sched_event.hh | 13144:61e0f3230787 Fri Aug 31 19:18:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Store timed notifications in a list instead of a set. This has three advantages. First, the data structure doesn't have to try to keep track of whether or not an event is already listed there. Second, it's easier to delete an item by storing an iterator for it when it gets inserted. Third, the ordering of events is not dependent on the arbitrary ordering of the set, it's bsaed on the fixed order the events get added to the list. One part of this change makes ScEvent-s keep track of what list they're on, and handle their own insertion and deletion when they're scheduled or descheduled. A side effect of that is that it's no longer safe to simply use a range based for loop to loop over all of an ScEvent and deschedule all its events or to run then (which deschedules them internally once they execute). That can be avoided by looping until the list is empty, and operating on the first element. As the first element is processed and removed from the list, the next element will become first and will get picked up in the next iteration. Change-Id: Icad51a63f153297c88e65f85d22ac721e6c571d8 Reviewed-on: https://gem5-review.googlesource.com/c/12456 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | scheduler.hh | 13144:61e0f3230787 Fri Aug 31 19:18:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Store timed notifications in a list instead of a set. This has three advantages. First, the data structure doesn't have to try to keep track of whether or not an event is already listed there. Second, it's easier to delete an item by storing an iterator for it when it gets inserted. Third, the ordering of events is not dependent on the arbitrary ordering of the set, it's bsaed on the fixed order the events get added to the list. One part of this change makes ScEvent-s keep track of what list they're on, and handle their own insertion and deletion when they're scheduled or descheduled. A side effect of that is that it's no longer safe to simply use a range based for loop to loop over all of an ScEvent and deschedule all its events or to run then (which deschedules them internally once they execute). That can be avoided by looping until the list is empty, and operating on the first element. As the first element is processed and removed from the list, the next element will become first and will get picked up in the next iteration. Change-Id: Icad51a63f153297c88e65f85d22ac721e6c571d8 Reviewed-on: https://gem5-review.googlesource.com/c/12456 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | scheduler.cc | 13144:61e0f3230787 Fri Aug 31 19:18:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Store timed notifications in a list instead of a set. This has three advantages. First, the data structure doesn't have to try to keep track of whether or not an event is already listed there. Second, it's easier to delete an item by storing an iterator for it when it gets inserted. Third, the ordering of events is not dependent on the arbitrary ordering of the set, it's bsaed on the fixed order the events get added to the list. One part of this change makes ScEvent-s keep track of what list they're on, and handle their own insertion and deletion when they're scheduled or descheduled. A side effect of that is that it's no longer safe to simply use a range based for loop to loop over all of an ScEvent and deschedule all its events or to run then (which deschedules them internally once they execute). That can be avoided by looping until the list is empty, and operating on the first element. As the first element is processed and removed from the list, the next element will become first and will get picked up in the next iteration. Change-Id: Icad51a63f153297c88e65f85d22ac721e6c571d8 Reviewed-on: https://gem5-review.googlesource.com/c/12456 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
Completed in 18 milliseconds