Adding a cpu model named simpleEdgeCPU into M5
Review Request #14 - Created April 28, 2010 and updated
Information | |
---|---|
Gou Pengfei | |
gem5 | |
Reviewers | |
Default | |
ali, nate |
Adding a cpu model named simpleEdgeCPU to support EDGE style execution. Most of these codes are borrowed from O3. There're some outstanding features: 1) 4-stage model including fetch, map, execute and commit, to target on modeling the common characteristics of EDGE. 2) Adding a class named edgeBlock to hold information of an EDGE inst block. Right now it is mainly for the TRIPS inst block. 3) Fetch will fetch instructions and form inst blocks. 4) Map is planned to implement some dynamic mapping algorithms but right it's just a dummy stage. 5) Execute will execute inst in EDGE style, say, waking dependent insts directly without renaming. 6) Commit will commit in granularity of inst blocks.
This model with TRIPS ISA support can run SPEC CPU2000 using test input set. build cmd lines: % scons CPU_MODELS=simpleEdgeCPU build/TRIPS_SE/m5.debug
Review request changed
Updated (April 28, 2010, 11:28 a.m.)
Change Summary:
Patches for CPU model
Description: |
|
|||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Testing Done: |
|
Review request changed
Updated (April 28, 2010, 11:52 a.m.)
Testing Done: |
|
---|
Posted (April 29, 2010, 5:22 p.m.)
This should be considered a first pass review which doesn't address every issue. I expect that future passes will be necessary. How much of the code here is directly copied from O3, and how much was modified or added for EDGE? It would be great if we could avoid all this duplication and share the common components between these CPUs. I realize O3 may not make that easy as it's written right now. It would also be great, although probably outside of the scope of what you're doing, to modularize/simplify O3's implementation so that's easier to do.
-
src/cpu/SConscript (Diff revision 1) -
Why do you need special function signatures here?
-
src/cpu/SConscript (Diff revision 1) -
This code will create exec signatures for all CPUs if any CPU is an edge CPU. I don't think that's what you wanted.
-
src/cpu/edge/SConscript (Diff revision 1) -
If your flag has the same name as an existing one, that's actually a good thing. That way users don't have to learn a new set of options for doing basically the same thing. If you turn on the "Fetch" trace flag for whatever CPU your using, you should see what's going on in the fetch stage. Making an Edge version is unnecessary specialization.
-
src/cpu/edge/base_dyn_inst_impl.hh (Diff revision 1) -
Don't comment out code, delete it.
-
src/cpu/edge/exetrace.cc (Diff revision 1) -
This file doesn't need to exist. You should just use the original, not a direct copy. If you did make any changes, you should subclass this. Also, you seem to have more than one tracer. You should only need one.
-
src/cpu/edge/insttracer.hh (Diff revision 1) -
I don't think this file needs to exist. You can just use the default tracer which this seems to just be a direct copy of. If you did make some modification, it should be a subclass, not a copy of the source. This removes the need to specially set the default tracer in BaseCPU.py.
-
src/cpu/simple_thread.hh (Diff revision 1) -
What is this function for? Why can't it be built out of some other existing mechanism?
-
src/cpu/simple_thread.cc (Diff revision 1) -
Don't commit whitespace only changes to a file.
-
src/cpu/static_inst.hh (Diff revision 1) -
This definitely doesn't go here. StaticInst is at a building block and should have no knowledge of TRIPS or the edge CPU.
-
src/cpu/static_inst.hh (Diff revision 1) -
What are these flags for? Can they be implemented in your subclasses? If they're only consumed in your ISA description they should be in a subclass. There shouldn't be any overt coupling between your ISA and your CPU model. If your CPU model needs these flags to work, we should try to figure out a way to move that to the ISA implementation and not force it on all the other CPU models and ISAs. M5 is complicated enough without details of their use leaking into generic components.