Searched hist:12456 (Results 1 - 5 of 5) sorted by relevance
| /gem5/src/systemc/core/ | ||
| H A D | sched_event.hh | diff 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 | diff 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 | diff 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> |
| /gem5/src/mem/ | ||
| H A D | multi_level_page_table.hh | diff 12456:9d042ae9dd5b Fri Jan 05 20:48:00 EST 2018 Gabe Black <gabeblack@google.com> x86, mem: Pass the multi level page table layout in as a parameter. Don't get it from a global constant declared in an ISA header file. Change-Id: Ie19440abdd76500a5e12e6791e6f755ad9e95af3 Reviewed-on: https://gem5-review.googlesource.com/7344 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> |
| /gem5/src/arch/x86/ | ||
| H A D | process.cc | diff 12456:9d042ae9dd5b Fri Jan 05 20:48:00 EST 2018 Gabe Black <gabeblack@google.com> x86, mem: Pass the multi level page table layout in as a parameter. Don't get it from a global constant declared in an ISA header file. Change-Id: Ie19440abdd76500a5e12e6791e6f755ad9e95af3 Reviewed-on: https://gem5-review.googlesource.com/7344 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Alexandru Duțu <alexandru.dutu@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> |
Completed in 189 milliseconds