Searched hist:8601 (Results 1 - 18 of 18) sorted by relevance
| /gem5/src/sim/power/ | ||
| H A D | power_model.cc | diff 12546:8182d78bebcb Wed Mar 01 12:05:00 EST 2017 Anouk Van Laer <anouk.vanlaer@arm.com> sim: Added model type to power model Static, dynamic or all to differentiate between types of power models so for example static models will not be asked for a dynamic power Change-Id: I3a0385821f7c671aedddaebeb038c677367faa81 Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/8601 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| H A D | power_model.hh | diff 12546:8182d78bebcb Wed Mar 01 12:05:00 EST 2017 Anouk Van Laer <anouk.vanlaer@arm.com> sim: Added model type to power model Static, dynamic or all to differentiate between types of power models so for example static models will not be asked for a dynamic power Change-Id: I3a0385821f7c671aedddaebeb038c677367faa81 Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/8601 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| H A D | PowerModel.py | diff 12546:8182d78bebcb Wed Mar 01 12:05:00 EST 2017 Anouk Van Laer <anouk.vanlaer@arm.com> sim: Added model type to power model Static, dynamic or all to differentiate between types of power models so for example static models will not be asked for a dynamic power Change-Id: I3a0385821f7c671aedddaebeb038c677367faa81 Reviewed-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/8601 Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/mem/ | ||
| H A D | page_table.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| H A D | page_table.hh | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/arm/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/power/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/arm/linux/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/alpha/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/mips/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/x86/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/arch/sparc/ | ||
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| /gem5/src/sim/ | ||
| H A D | process.hh | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| H A D | system.hh | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| H A D | system.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| H A D | syscall_emul.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| H A D | syscall_emul.hh | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
| H A D | process.cc | diff 8601:af28085882dc Sun Oct 23 01:30:00 EDT 2011 Steve Reinhardt <steve.reinhardt@amd.com> SE: move page allocation from PageTable to Process PageTable supported an allocate() call that called back through the Process to allocate memory, but did not have a method to map addresses without allocating new pages. It makes more sense for Process to do the allocation, so this method was renamed allocateMem() and moved to Process, and uses a new map() call on PageTable. The remaining uses of the process pointer in PageTable were only to get the name and the PID, so by passing these in directly in the constructor, we can make PageTable completely independent of Process. |
Completed in 306 milliseconds