Searched hist:76 (Results 101 - 125 of 162) sorted by relevance
| /gem5/src/arch/alpha/ | ||
| H A D | locked_mem.hh | 5714:76abee886def Sun Nov 02 21:57:00 EST 2008 Lisa Hsu <hsul@eecs.umich.edu> Add in Context IDs to the simulator. From now on, cpuId is almost never used, the primary identifier for a hardware context should be contextId(). The concept of threads within a CPU remains, in the form of threadId() because sometimes you need to know which context within a cpu to manipulate. |
| H A D | system.cc | 3567:76b849656311 Tue Nov 07 23:40:00 EST 2006 Gabe Black <gblack@eecs.umich.edu> Force remote gdb code to use signal numbers and not ISA specific trap numbers. |
| /gem5/src/arch/mips/ | ||
| H A D | locked_mem.hh | 5714:76abee886def Sun Nov 02 21:57:00 EST 2008 Lisa Hsu <hsul@eecs.umich.edu> Add in Context IDs to the simulator. From now on, cpuId is almost never used, the primary identifier for a hardware context should be contextId(). The concept of threads within a CPU remains, in the form of threadId() because sometimes you need to know which context within a cpu to manipulate. |
| /gem5/src/dev/alpha/ | ||
| H A D | tsunami_cchip.cc | 5714:76abee886def Sun Nov 02 21:57:00 EST 2008 Lisa Hsu <hsul@eecs.umich.edu> Add in Context IDs to the simulator. From now on, cpuId is almost never used, the primary identifier for a hardware context should be contextId(). The concept of threads within a CPU remains, in the form of threadId() because sometimes you need to know which context within a cpu to manipulate. |
| /gem5/src/cpu/o3/probe/ | ||
| H A D | elastic_trace.cc | 11247:76f75db08e09 Mon Dec 07 17:42:00 EST 2015 Radhika Jagtap <radhika.jagtap@ARM.com> proto, probe: Add elastic trace probe to o3 cpu The elastic trace is a type of probe listener and listens to probe points in multiple stages of the O3CPU. The notify method is called on a probe point typically when an instruction successfully progresses through that stage. As different listener methods mapped to the different probe points execute, relevant information about the instruction, e.g. timestamps and register accesses, are captured and stored in temporary InstExecInfo class objects. When the instruction progresses through the commit stage, the timing and the dependency information about the instruction is finalised and encapsulated in a struct called TraceInfo. TraceInfo objects are collected in a list instead of writing them out to the trace file one a time. This is required as the trace is processed in chunks to evaluate order dependencies and computational delay in case an instruction does not have any register dependencies. By this we achieve a simpler algorithm during replay because every record in the trace can be hooked onto a record in its past. The instruction dependency trace is written out as a protobuf format file. A second trace containing fetch requests at absolute timestamps is written to a separate protobuf format file. If the instruction is not executed then it is not added to the trace. The code checks if the instruction had a fault, if it predicated false and thus previous register values were restored or if it was a load/store that did not have a request (e.g. when the size of the request is zero). In all these cases the instruction is set as executed by the Execute stage and is picked up by the commit probe listener. But a request is not issued and registers are not written. So practically, skipping these should not hurt the dependency modelling. If squashing results in squashing younger instructions, it may happen that the squash probe discards the inst and removes it from the temporary store but execute stage deals with the instruction in the next cycle which results in the execute probe seeing this inst as 'new' inst. A sequence number of the last processed trace record is used to trap these cases and not add to the temporary store. The elastic instruction trace and fetch request trace can be read in and played back by the TraceCPU. |
| /gem5/src/mem/cache/prefetch/ | ||
| H A D | stride.hh | 5714:76abee886def Sun Nov 02 21:57:00 EST 2008 Lisa Hsu <hsul@eecs.umich.edu> Add in Context IDs to the simulator. From now on, cpuId is almost never used, the primary identifier for a hardware context should be contextId(). The concept of threads within a CPU remains, in the form of threadId() because sometimes you need to know which context within a cpu to manipulate. |
| H A D | stride.cc | 5714:76abee886def Sun Nov 02 21:57:00 EST 2008 Lisa Hsu <hsul@eecs.umich.edu> Add in Context IDs to the simulator. From now on, cpuId is almost never used, the primary identifier for a hardware context should be contextId(). The concept of threads within a CPU remains, in the form of threadId() because sometimes you need to know which context within a cpu to manipulate. |
| /gem5/src/arch/arm/ | ||
| H A D | pmu.cc | 13638:76cb1cecc057 Thu Jan 31 04:52:00 EST 2019 Giacomo Travaglini <giacomo.travaglini@arm.com> arch-arm: Allow ArmPPI usage for PMU Differently from ArmSPIs, ArmPPI interrupts need to be instantiated by giving a ThreadContext pointer in the ArmPPIGen::get() method. Since the PMU is registering the ThreadContext only at ISA startup time, ArmPPI generation in deferred until the PMU has a non NULL pointer. Change-Id: I17daa6f0e355363b8778d707b440cab9f75aaea2 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/c/16204 Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
| /gem5/src/systemc/core/ | ||
| H A D | scheduler.hh | 13203:76ee4971fd9e Tue Sep 11 19:16:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Add some error checks to some classes. These check whether those classes are being constructed in legal circumstances, and avoids a null pointer dereference. Change-Id: Ied36ee15c3d7bf6ee444351a841c38576780298e Reviewed-on: https://gem5-review.googlesource.com/c/12622 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> 13176:76f52e8d8c6a Wed Sep 05 20:21:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Match how Accellera schedules processes even more closely. The Accellera implementation runs processes in a cycle where it first runs all the methods it has, then all the threads, and then starts again in case any new methods have been scheduled. This keeps methods and processes in the order they were marked ready (what a prior change made this scheduler do), but also keeps the methods together and the threads together (something it used to do, but that change made it stop doing). This change should make the gem5 scheduler match in both respects. Note that its correct to run the processes in whatever order we want, it's just that if we're going to compare against the "golden" output from the Accellera tests, we need to match the order to get sensible results. Change-Id: I0b1e4ed24c56f97921148b74e90c2dca5fd3fbc4 Reviewed-on: https://gem5-review.googlesource.com/c/12595 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| H A D | scheduler.cc | 13203:76ee4971fd9e Tue Sep 11 19:16:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Add some error checks to some classes. These check whether those classes are being constructed in legal circumstances, and avoids a null pointer dereference. Change-Id: Ied36ee15c3d7bf6ee444351a841c38576780298e Reviewed-on: https://gem5-review.googlesource.com/c/12622 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> 13176:76f52e8d8c6a Wed Sep 05 20:21:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Match how Accellera schedules processes even more closely. The Accellera implementation runs processes in a cycle where it first runs all the methods it has, then all the threads, and then starts again in case any new methods have been scheduled. This keeps methods and processes in the order they were marked ready (what a prior change made this scheduler do), but also keeps the methods together and the threads together (something it used to do, but that change made it stop doing). This change should make the gem5 scheduler match in both respects. Note that its correct to run the processes in whatever order we want, it's just that if we're going to compare against the "golden" output from the Accellera tests, we need to match the order to get sensible results. Change-Id: I0b1e4ed24c56f97921148b74e90c2dca5fd3fbc4 Reviewed-on: https://gem5-review.googlesource.com/c/12595 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
| /gem5/tests/configs/ | ||
| H A D | simple-atomic-mp.py | 4390:76bbcf725852 Sun Apr 22 14:39:00 EDT 2007 Kevin Lim <ktlim@umich.edu> Update configs to set the CPU clock properly. |
| H A D | simple-timing-mp.py | 4390:76bbcf725852 Sun Apr 22 14:39:00 EDT 2007 Kevin Lim <ktlim@umich.edu> Update configs to set the CPU clock properly. |
| H A D | simple-timing.py | 4390:76bbcf725852 Sun Apr 22 14:39:00 EDT 2007 Kevin Lim <ktlim@umich.edu> Update configs to set the CPU clock properly. |
| /gem5/tests/quick/fs/10.linux-boot/ref/arm/linux/realview-simple-timing-dual/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/00.hello/ref/alpha/linux/o3-timing/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/00.hello/ref/arm/linux/o3-timing/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/00.hello/ref/arm/linux/o3-timing-checker/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/00.hello/ref/mips/linux/o3-timing/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/00.hello/ref/power/linux/o3-timing/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/00.hello/ref/x86/linux/o3-timing/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/tests/quick/se/02.insttest/ref/sparc/linux/o3-timing/ | ||
| H A D | stats.txt | 11440:76b5639162af Fri Apr 08 12:01:00 EDT 2016 Curtis Dunham <Curtis.Dunham@arm.com> stats: update stats for thermals, indirect BP |
| /gem5/src/cpu/ | ||
| H A D | thread_context.cc | 5714:76abee886def Sun Nov 02 21:57:00 EST 2008 Lisa Hsu <hsul@eecs.umich.edu> Add in Context IDs to the simulator. From now on, cpuId is almost never used, the primary identifier for a hardware context should be contextId(). The concept of threads within a CPU remains, in the form of threadId() because sometimes you need to know which context within a cpu to manipulate. |
| /gem5/src/mem/ | ||
| H A D | coherent_xbar.hh | 11859:76c36516e0ae Sun Feb 19 05:30:00 EST 2017 Andreas Hansson <andreas.hansson@arm.com> sim: Ensure draining is deterministic The traversal of drainable objects could potentially be non-deterministic when using an unordered set containing object pointers. To ensure that the iteration is deterministic, we switch to a vector. Note that the lookup and traversal of the drainable objects is not performance critical, so the change has no negative consequences. |
| /gem5/src/arch/arm/isa/formats/ | ||
| H A D | fp.isa | 7335:76f94f8ed949 Wed Jun 02 01:58:00 EDT 2010 Gabe Black <gblack@eecs.umich.edu> ARM: Decode all the various forms of vmov. |
| /gem5/src/cpu/minor/ | ||
| H A D | execute.cc | 12489:76d7f5f55f40 Wed Nov 08 06:24:00 EST 2017 Giacomo Travaglini <giacomo.travaglini@arm.com> cpu: MinorCPU handling IsSquashAfter flag MinorCPU was not handling IsSquashAfter flagged instructions. The behaviour was to force a branch (hence enforcing refetching) for SerializeAfter instructions only. This has now been extended to SquashAfter in order to correctly support ISB barrier instruction behaviour. Change-Id: Ie525b23350b0de121372d3b98b433e36b097d5c4 Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com> Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-on: https://gem5-review.googlesource.com/5702 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com> |
Completed in 123 milliseconds