#
12236:126ac9da6050 |
|
04-Nov-2017 |
Gabe Black <gabeblack@google.com> |
alpha,arm,mips,power,riscv,sparc,x86: Merge exec decl templates.
In the ISA instruction definitions, some classes were declared with execute, etc., functions outside of the main template because they had CPU specific signatures and would need to be duplicated with each CPU plugged into them. Now that the instructions always just use an ExecContext, there's no reason for those templates to be separate. This change folds those templates together.
Change-Id: I13bda247d3d1cc07c0ea06968e48aa5b4aace7fa Reviewed-on: https://gem5-review.googlesource.com/5401 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Reviewed-by: Alec Roelke <ar4jc@virginia.edu> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
#
12234:78ece221f9f5 |
|
02-Nov-2017 |
Gabe Black <gabeblack@google.com> |
alpha,arm,mips,power,riscv,sparc,x86,isa: De-specialize ExecContexts.
The ISA parser used to generate different copies of exec functions for each exec context class a particular CPU wanted to use. That's since been changed so that those functions take a pointer to the base ExecContext, so the code which would generate those extra functions can be removed, and some functions which used to be templated on an ExecContext subclass can be untemplated, or minimally less templated.
Now that some functions aren't going to be instantiated multiple times with different signatures, there are also opportunities to collapse templates and make many instruction definitions simpler within the parser. Since those changes will be less mechanical, they're left for later changes and will probably be done in smaller increments.
Change-Id: I0015307bb02dfb9c60380b56d2a820f12169ebea Reviewed-on: https://gem5-review.googlesource.com/5381 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> Maintainer: Andreas Sandberg <andreas.sandberg@arm.com>
|
#
11303:f694764d656d |
|
17-Jan-2016 |
Steve Reinhardt <steve.reinhardt@amd.com> |
cpu. arch: add initiateMemRead() to ExecContext interface
For historical reasons, the ExecContext interface had a single function, readMem(), that did two different things depending on whether the ExecContext supported atomic memory mode (i.e., AtomicSimpleCPU) or timing memory mode (all the other models). In the former case, it actually performed a memory read; in the latter case, it merely initiated a read access, and the read completion did not happen until later when a response packet arrived from the memory system.
This led to some confusing things, including timing accesses being required to provide a pointer for the return data even though that pointer was only used in atomic mode.
This patch splits this interface, adding a new initiateMemRead() function to the ExecContext interface to replace the timing-mode use of readMem().
For consistency and clarity, the readMemTiming() helper function in the ISA definitions is renamed to initiateMemRead() as well. For x86, where the access size is passed in explicitly, we can also get rid of the data parameter at this level. For other ISAs, where the access size is determined from the type of the data parameter, we have to keep the parameter for that purpose.
|
#
10773:16643e7b322a |
|
03-Apr-2015 |
Lena Olson <lena@cs.wisc.edu> |
x86: fix debug trace output for mwait
When running with the Exec flag, the mwait instruction attempted to print out its source registers, which were never actually initialized. This led to sporadic assertion failures when the value stored there was invalid.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
|
#
10529:05b5a6cf3521 |
|
06-Nov-2014 |
Marc Orr <morr@cs.wisc.edu> |
x86 isa: This patch attempts an implementation at mwait.
Mwait works as follows: 1. A cpu monitors an address of interest (monitor instruction) 2. A cpu calls mwait - this loads the cache line into that cpu's cache. 3. The cpu goes to sleep. 4. When another processor requests write permission for the line, it is evicted from the sleeping cpu's cache. This eviction is forwarded to the sleeping cpu, which then wakes up.
Committed by: Nilay Vaish <nilay@cs.wisc.edu>
|