Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 25, 2015, 4:26 a.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK Curtis Dunham wrote: I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). Steve Reinhardt wrote: I see... I was confused because EventQueue::deschedule() asserts if the event is not scheduled. It seems inconsistent that deschedule() behaves differently for global events. I can understand the caution in BaseGlobalEvent::deschedule(), where it's at least theoretically possible that some of the local sub-events have been reached so they are no longer scheduled, but descheduling an event that's already half-executed seems like a really bad idea anyway. Is there a situation where that could legitimately happen? I can't think of one. Also, note that BaseGlobalEvent::deschedule() never checks whether the global event is scheduled, though that's partly because BaseGlobalEvent doesn't even track its own scheduled/descheduled status. Which would make adding a single check here in the destructor difficult as well... So when does the GlobalSimLoopExitEvent get destroyed anyway? Now that we're allocating it dynamically, the destructor shouldn't get called implicitly; and if we call it explicitly, we can just explicitly call deschedule() right before then, right? Can we just drop this? I understand the confusion - the scheduling interfaces across the family of Event* classes isn't entirely consistent. You bring up a good point about the destruction, as the last tweak made it heap allocated rather than an initialized-on-demand static. I will check on this and update as such if it works! Thanks for the careful feedback. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On Feb. 25, 2015, 1:22 a.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 25, 2015, 1:22 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 12:56 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 src/mem/ExternalSlave.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 1:04 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated March 3, 2015, 11:43 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs (updated) - src/sim/simulate.hh 8a20e2a1562debfc20b92be4581457c4147b3733 src/sim/simulate.cc 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 12:47 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 src/mem/ExternalSlave.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 1:07 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs (updated) - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote: Took me longer to review this just because I'm not sure what to think of it. It's not pretty, but I don't have better ideas, so it's hard to object. One thing that bothers me is that, while it's noble to try and generalize things, despite the generic-sounding --external-memory-system switch, many of the low-level details seem very sst-specific (like 'port_type=sst' as an obvious one). Would it be more appropriate just to call the option --sst-memory? Also, the ExternalCache thing looks like it should be a subclass, even though it's just a function. I can see how the function is more convenient, but making it a subclass would allow some better encapsulation of the cpu_side __getattr__/__setattr__ hack. These are just general thoughts though... I'm very interested in others' input. Curtis Dunham wrote: There is some truth to this complaint. I think there is a little room for improvement, though. It's ready for another look at diff r5. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/#review5914 --- On March 4, 2015, 1:07 a.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- (Updated March 4, 2015, 1:07 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs - configs/common/CacheConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/FSConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/MemConfig.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/common/Options.py 8a20e2a1562debfc20b92be4581457c4147b3733 configs/example/fs.py 8a20e2a1562debfc20b92be4581457c4147b3733 ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 25, 2015, 4:26 a.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK Curtis Dunham wrote: I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). Steve Reinhardt wrote: I see... I was confused because EventQueue::deschedule() asserts if the event is not scheduled. It seems inconsistent that deschedule() behaves differently for global events. I can understand the caution in BaseGlobalEvent::deschedule(), where it's at least theoretically possible that some of the local sub-events have been reached so they are no longer scheduled, but descheduling an event that's already half-executed seems like a really bad idea anyway. Is there a situation where that could legitimately happen? I can't think of one. Also, note that BaseGlobalEvent::deschedule() never checks whether the global event is scheduled, though that's partly because BaseGlobalEvent doesn't even track its own scheduled/descheduled status. Which would make adding a single check here in the destructor difficult as well... So when does the GlobalSimLoopExitEvent get destroyed anyway? Now that we're allocating it dynamically, the destructor shouldn't get called implicitly; and if we call it explicitly, we can just explicitly call deschedule() right before then, right? Can we just drop this? Curtis Dunham wrote: I understand the confusion - the scheduling interfaces across the family of Event* classes isn't entirely consistent. You bring up a good point about the destruction, as the last tweak made it heap allocated rather than an initialized-on-demand static. I will check on this and update as such if it works! Thanks for the careful feedback. Steve Reinhardt wrote: Yes, in thinking about the right way to deal with this, most of my solutions involved tweaking the event functions themselves to be more consistent, which let to questions about whether that would actually work (e.g., taking the scheduled() check out of BaseGlobalEvent::deschedule()). I didn't want to burden you with that, but at the same time I wasn't happy with putting in a workaround either. If we can sidestep the issue entirely, then we can just move on until someone else messes with this code :). Testing went well, so I dropped this tweak. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On March 3, 2015, 11:43 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated March 3, 2015, 11:43 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/simulate.hh 8a20e2a1562debfc20b92be4581457c4147b3733 src/sim/simulate.cc 8a20e2a1562debfc20b92be4581457c4147b3733 Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2667: ext: Add SST connector
On Feb. 25, 2015, 1:55 a.m., Nathan Binkert wrote:
Not to be difficult, but is it possible for Sandia to just use the standard
gem5 license (which is basically the same thing you've already got)? And
if yes, can we just include it in the main tree instead of ext?
I've reached out to them in case they want to comment on this.
I don't understand the benefit of putting it in the main tree - where would it
ideally live? The connector doesn't link into the primary gem5 targets anyway
- it builds its own .so that, when loaded by SST, then loads
libgem5_{opt,debug,fast}.so.
- Curtis
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2667/#review5912
---
On Feb. 25, 2015, 1:16 a.m., Curtis Dunham wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2667/
---
(Updated Feb. 25, 2015, 1:16 a.m.)
Review request for Default.
Repository: gem5
Description
---
Changeset 10708:344bc6b7203d
---
ext: Add SST connector
This patch adds a connector that allows gem5 to be used as a component
in SST (Structural Simulation Toolkit, sst-simulator.org). At a high
level, this allows memory traffic to pass between the two simulators.
SST Links are roughly analogous to gem5 Ports, although Links do not
have a notion of master and slave. This distinction is important to
gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave
must be used, and similarly when connecting the memory side of SST cache
to a gem5 port (for memory - I/O), an ExternalMaster must be used.
These connectors handle the administrative aspects of gem5
(initialization, simulation, shutdown) as well as translating SST's
MemEvents into gem5 Packets and vice-versa.
Diffs
-
ext/sst/ExtMaster.hh PRE-CREATION
ext/sst/ExtMaster.cc PRE-CREATION
ext/sst/ExtSlave.hh PRE-CREATION
ext/sst/ExtSlave.cc PRE-CREATION
ext/sst/LICENSE PRE-CREATION
ext/sst/Makefile PRE-CREATION
ext/sst/README PRE-CREATION
ext/sst/gem5.hh PRE-CREATION
ext/sst/gem5.cc PRE-CREATION
ext/sst/libgem5.cc PRE-CREATION
Diff: http://reviews.gem5.org/r/2667/diff/
Testing
---
Thanks,
Curtis Dunham
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
Took me longer to review this just because I'm not sure what to think of
it. It's not pretty, but I don't have better ideas, so it's hard to object.
One thing that bothers me is that, while it's noble to try and generalize
things, despite the generic-sounding --external-memory-system switch,
many of the low-level details seem very sst-specific (like
'port_type=sst' as an obvious one). Would it be more appropriate just to
call the option --sst-memory?
Also, the ExternalCache thing looks like it should be a subclass, even
though it's just a function. I can see how the function is more
convenient, but making it a subclass would allow some better encapsulation
of the cpu_side __getattr__/__setattr__ hack.
These are just general thoughts though... I'm very interested in others'
input.
There is some truth to this complaint. I think there is a little room for
improvement, though.
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
configs/common/CacheConfig.py, line 130
http://reviews.gem5.org/r/2668/diff/1/?file=43775#file43775line130
I assume this naming is also specific to sst
Not here.
The naming just has to agree with the configuration on the other side, which
in this case is the ext/sst/tests/test6_arm_4c.py in this patchset. However as
long as any other simulator we hook up with is cool with the same naming, it
doesn't need to be changed.
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
configs/common/CacheConfig.py, line 50
http://reviews.gem5.org/r/2668/diff/1/?file=43775#file43775line50
This seems obviously specific to sst here
Correct that port_type=sst is SST specific because the
ext/sst/Ext{Master,Slave} code registers a handler for handler_name sst.
Perhaps --external-memory-system could take a string argument that could be
stuck here? We'd use --external-memory-system=sst on the command line.
On Feb. 25, 2015, 4:32 p.m., Steve Reinhardt wrote:
src/mem/ExternalSlave.py, line 57
http://reviews.gem5.org/r/2668/diff/1/?file=43782#file43782line57
To me, this clearly straddles the line between clever and
horrifying :). If nothing else, it would be nice to put these in an
ExternalCache subclass.
Clever/Horrifying... Yes. :)
My concern here is that creating a new class doesn't seem to solve the problem.
As best I can tell, you just end up moving this unsightly hack to the new
class instead. But the value of not having to create new conditional
statements to set either port (for external memory) or cpu_side (for gem5's
internal caches) seems worth this bit of nastiness.
- Curtis
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2668/#review5914
---
On Feb. 20, 2015, 6:47 p.m., Curtis Dunham wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2668/
---
(Updated Feb. 20, 2015, 6:47 p.m.)
Review request for Default.
Repository: gem5
Description
---
Changeset 10709:a3b771cd744c
---
config: Support full-system with SST's memory system
This patch adds an example configuration in ext/sst/tests/ that allows
an SST/gem5 instance to simulate a 4-core AArch64 system with SST's
memHierarchy components providing all the caches and memories.
Diffs
-
configs/common/CacheConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/common/FSConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/common/MemConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af
configs/example/fs.py c6cb94a14fea4c59780d73d1623d7031bcede6af
ext/sst/tests/test6_arm_4c.py PRE-CREATION
src/dev/arm/RealView.py c6cb94a14fea4c59780d73d1623d7031bcede6af
src/mem/ExternalSlave.py c6cb94a14fea4c59780d73d1623d7031bcede6af
Diff: http://reviews.gem5.org/r/2668/diff/
Testing
---
Thanks,
Curtis Dunham
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 25, 2015, 4:26 a.m., Steve Reinhardt wrote: src/sim/sim_events.hh, line 77 http://reviews.gem5.org/r/2665/diff/2/?file=43797#file43797line77 seems like it would be safer just to say: if (scheduled()) deschedule(); then if some derived class no longer meets the condition of always being scheduled, we'll still be OK I can do this, however I originally made this trade-off because BaseGlobalEvent::deschedule() already checks for scheduled(). - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5913 --- On Feb. 25, 2015, 1:22 a.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 25, 2015, 1:22 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2667: ext: Add SST connector
On Feb. 24, 2015, 5:29 p.m., Steve Reinhardt wrote: Just curious: what's the motivation for including this code with gem5 and not with SST? I'm not necessarily opposed, just wondering whether you considered putting this code in the SST distribution instead. Yes, both ways were considered. gem5 binds tighter in many ways than SST which led to this approach being taken. For instance, SST dynamically loads its Components (~SimObjects) whereas gem5 does not. Keeping it in our tree is the better of the two options. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/#review5901 --- On Feb. 20, 2015, 6:47 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/ --- (Updated Feb. 20, 2015, 6:47 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10708:344bc6b7203d --- ext: Add SST connector This patch adds a connector that allows gem5 to be used as a component in SST (Structural Simulation Toolkit, sst-simulator.org). At a high level, this allows memory traffic to pass between the two simulators. SST Links are roughly analogous to gem5 Ports, although Links do not have a notion of master and slave. This distinction is important to gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave must be used, and similarly when connecting the memory side of SST cache to a gem5 port (for memory - I/O), an ExternalMaster must be used. These connectors handle the administrative aspects of gem5 (initialization, simulation, shutdown) as well as translating SST's MemEvents into gem5 Packets and vice-versa. Diffs - ext/sst/ExtMaster.hh PRE-CREATION ext/sst/ExtMaster.cc PRE-CREATION ext/sst/ExtSlave.hh PRE-CREATION ext/sst/ExtSlave.cc PRE-CREATION ext/sst/LICENSE PRE-CREATION ext/sst/Makefile PRE-CREATION ext/sst/README PRE-CREATION ext/sst/gem5.hh PRE-CREATION ext/sst/gem5.cc PRE-CREATION ext/sst/libgem5.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2667/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 24, 2015, 5:17 p.m., Steve Reinhardt wrote: I like the idea of having a single global limit event, with a function to access it so clients can check whether that's what was hit. However I don't think the GlobalSimLoopExitEvent should be a singleton, as there are a bunch of other instances that get created (see exitSimLoop() in sim_events.cc). I think it's clearer just to have a global variable for limit_event. (One of the extremely rare cases where a global variable is OK.) There's already support in simulate() for first-time initialization with the threads_initialized flag. I think we should basically leverage this flag to create the global limit_event (rename the flag if you want to make it more general). We may want to take the static vars inside simulate() and make them all global for consistency; I don't have a strong opinion there. Curtis Dunham wrote: Maybe I should just change the comment. I'm not actually making GlobalSimLoopExitEvent a (simulator-wide) singleton, but rather just a static with respect to simulate(). Because of how it schedules the event, the destructor needs to deschedule it. I wrapped simulate()'s instance in a function to deal with static initialization ordering issues. The other uses of GlobalSimLoopExitEvent should still work. Steve Reinhardt wrote: Yea, I read the description first, and my initial reaction on looking at the code was if you're going to make it a singleton you should really put it inside the class, and later I realized you don't really want a singleton here, and I didn't really go back to square one to see that it was not-really-a-singleton *because* you don't really want a singleton. However, overriding the destructor is a little weird if it only applies to that instance... can you elaborate a little more on why that's necessary? Nevertheless, I still think that just making a plain ol' global variable is clearer and cleaner. Sure. In summary, it's not strictly necessary: the descheduling upon destruction is because simulate() doesn't deschedule it, and the destructor will assert and die if trying to destroy a scheduled event (of any kind - I personally think this is a bit heavy-handed for an exit event...) Now, we could change simulate() so that it does deschedule it on every call to simulate(). I was avoiding the overhead of doing that since it needs to be scheduled again immediately anyway (more specifically, rescheduled). It just seemed wasteful to muck around in the event queue that extra time, every 1000 ticks. Still, I think it could be changed. As for the global variable, I had trouble with that due to static/global object construction in C++. When using gem5 loaded as an .so into another simulator, it would get to that point and the object wouldn't be constructed. The standard C++ recipe for that is to wrap it in a method so it gets constructed on first use. Mildly unpleasant, but not as unpleasant as a segfault. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5899 --- On Feb. 20, 2015, 6:46 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 20, 2015, 6:46 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate()'s GlobalSimLoopExitEvent a singleton reused across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can call getLimitEvent() and compare it to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 25, 2015, 1:22 a.m.) Review request for Default. Changes --- Correct the patch description. Repository: gem5 Description (updated) --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate() reuse the same GlobalSimLoopExitEvent across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can compare the global simulate_limit_event to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 25, 2015, 1:16 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate()'s GlobalSimLoopExitEvent a singleton reused across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can call getLimitEvent() and compare it to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs (updated) - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2667: ext: Add SST connector
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/ --- (Updated Feb. 25, 2015, 1:16 a.m.) Review request for Default. Repository: gem5 Description --- Changeset 10708:344bc6b7203d --- ext: Add SST connector This patch adds a connector that allows gem5 to be used as a component in SST (Structural Simulation Toolkit, sst-simulator.org). At a high level, this allows memory traffic to pass between the two simulators. SST Links are roughly analogous to gem5 Ports, although Links do not have a notion of master and slave. This distinction is important to gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave must be used, and similarly when connecting the memory side of SST cache to a gem5 port (for memory - I/O), an ExternalMaster must be used. These connectors handle the administrative aspects of gem5 (initialization, simulation, shutdown) as well as translating SST's MemEvents into gem5 Packets and vice-versa. Diffs (updated) - ext/sst/ExtMaster.hh PRE-CREATION ext/sst/ExtMaster.cc PRE-CREATION ext/sst/ExtSlave.hh PRE-CREATION ext/sst/ExtSlave.cc PRE-CREATION ext/sst/LICENSE PRE-CREATION ext/sst/Makefile PRE-CREATION ext/sst/README PRE-CREATION ext/sst/gem5.hh PRE-CREATION ext/sst/gem5.cc PRE-CREATION ext/sst/libgem5.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2667/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2667: ext: Add SST connector
On Feb. 24, 2015, 10:24 p.m., Steve Reinhardt wrote: ext/sst/ExtMaster.cc, line 43 http://reviews.gem5.org/r/2667/diff/1/?file=43756#file43756line43 Why is the ARM license repeated in every file, but the (shorter) Sandia license is just included by reference? Seems inconsistent. Agreed, it is stylistically inconsistent. It's the way they include their license in SST and I didn't think to change it. On Feb. 24, 2015, 10:24 p.m., Steve Reinhardt wrote: ext/sst/Makefile, line 12 http://reviews.gem5.org/r/2667/diff/1/?file=43760#file43760line12 What if you want to use one of the non-opt builds (like fast or debug)? If nothing else, a comment saying that you need to edit this line to do so would be nice, even if it's not worth doing something fancier. Good point, I will put a comment / put some verbiage in the documentation. On Feb. 24, 2015, 10:24 p.m., Steve Reinhardt wrote: ext/sst/README, line 1 http://reviews.gem5.org/r/2667/diff/1/?file=43761#file43761line1 Please include a description here, similar to what's in the commit message, so people can know what this is before they're told how to use it :). I agree. :) I'll roughly #include the description/commit message into this file. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/#review5907 --- On Feb. 20, 2015, 6:47 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/ --- (Updated Feb. 20, 2015, 6:47 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10708:344bc6b7203d --- ext: Add SST connector This patch adds a connector that allows gem5 to be used as a component in SST (Structural Simulation Toolkit, sst-simulator.org). At a high level, this allows memory traffic to pass between the two simulators. SST Links are roughly analogous to gem5 Ports, although Links do not have a notion of master and slave. This distinction is important to gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave must be used, and similarly when connecting the memory side of SST cache to a gem5 port (for memory - I/O), an ExternalMaster must be used. These connectors handle the administrative aspects of gem5 (initialization, simulation, shutdown) as well as translating SST's MemEvents into gem5 Packets and vice-versa. Diffs - ext/sst/ExtMaster.hh PRE-CREATION ext/sst/ExtMaster.cc PRE-CREATION ext/sst/ExtSlave.hh PRE-CREATION ext/sst/ExtSlave.cc PRE-CREATION ext/sst/LICENSE PRE-CREATION ext/sst/Makefile PRE-CREATION ext/sst/README PRE-CREATION ext/sst/gem5.hh PRE-CREATION ext/sst/gem5.cc PRE-CREATION ext/sst/libgem5.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2667/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
On Feb. 24, 2015, 5:17 p.m., Steve Reinhardt wrote: I like the idea of having a single global limit event, with a function to access it so clients can check whether that's what was hit. However I don't think the GlobalSimLoopExitEvent should be a singleton, as there are a bunch of other instances that get created (see exitSimLoop() in sim_events.cc). I think it's clearer just to have a global variable for limit_event. (One of the extremely rare cases where a global variable is OK.) There's already support in simulate() for first-time initialization with the threads_initialized flag. I think we should basically leverage this flag to create the global limit_event (rename the flag if you want to make it more general). We may want to take the static vars inside simulate() and make them all global for consistency; I don't have a strong opinion there. Curtis Dunham wrote: Maybe I should just change the comment. I'm not actually making GlobalSimLoopExitEvent a (simulator-wide) singleton, but rather just a static with respect to simulate(). Because of how it schedules the event, the destructor needs to deschedule it. I wrapped simulate()'s instance in a function to deal with static initialization ordering issues. The other uses of GlobalSimLoopExitEvent should still work. Steve Reinhardt wrote: Yea, I read the description first, and my initial reaction on looking at the code was if you're going to make it a singleton you should really put it inside the class, and later I realized you don't really want a singleton here, and I didn't really go back to square one to see that it was not-really-a-singleton *because* you don't really want a singleton. However, overriding the destructor is a little weird if it only applies to that instance... can you elaborate a little more on why that's necessary? Nevertheless, I still think that just making a plain ol' global variable is clearer and cleaner. Curtis Dunham wrote: Sure. In summary, it's not strictly necessary: the descheduling upon destruction is because simulate() doesn't deschedule it, and the destructor will assert and die if trying to destroy a scheduled event (of any kind - I personally think this is a bit heavy-handed for an exit event...) Now, we could change simulate() so that it does deschedule it on every call to simulate(). I was avoiding the overhead of doing that since it needs to be scheduled again immediately anyway (more specifically, rescheduled). It just seemed wasteful to muck around in the event queue that extra time, every 1000 ticks. Still, I think it could be changed. As for the global variable, I had trouble with that due to static/global object construction in C++. When using gem5 loaded as an .so into another simulator, it would get to that point and the object wouldn't be constructed. The standard C++ recipe for that is to wrap it in a method so it gets constructed on first use. Mildly unpleasant, but not as unpleasant as a segfault. Steve Reinhardt wrote: Sounds like maybe the right answer is to fix the Event destructor... if it's checking whether the event is scheduled anyway, maybe it should just call deschedule() instead of complaining. Maybe print a warning if we're really worried about it being an issue. I was picturing a global pointer variable that you would explicitly initialize in simulate(), in the one-time-only block that's already there and protected bu threads_initialized. Okay, I see what you are suggesting. I will turn the crank on that and repost. As for the Event destructor, while I did find it overly restrictive, I didn't want to get sidetracked in a major refactoring. Were we to issue a warn(), it would be helpful to know what event is being destroyed. But then you realize we've already unwound the polymorphism all the way down to Event and it doesn't have much interesting information... - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/#review5899 --- On Feb. 20, 2015, 6:46 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- (Updated Feb. 20, 2015, 6:46 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate()'s GlobalSimLoopExitEvent a singleton reused across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate()
Re: [gem5-dev] Review Request 2669: config: Add --sst configuration option
On Feb. 24, 2015, 5:48 p.m., Steve Reinhardt wrote: To be honest, if you've got three lines worth of options you have to type anyway (and thus end up embedding the command in another script), then the value of this seems pretty marginal to me. This is a reasonable complaint. Over time, it became less and less useful. I'll discard. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2669/#review5903 --- On Feb. 20, 2015, 6:47 p.m., Curtis Dunham wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2669/ --- (Updated Feb. 20, 2015, 6:47 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10710:98bd34bb7a39 --- config: Add --sst configuration option This new option expands to the following: --external-memory-system --initialize-only These are required when running gem5 within SST. Diffs - configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION Diff: http://reviews.gem5.org/r/2669/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2669: config: Add --sst configuration option
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2669/ --- Review request for Default. Repository: gem5 Description --- Changeset 10710:98bd34bb7a39 --- config: Add --sst configuration option This new option expands to the following: --external-memory-system --initialize-only These are required when running gem5 within SST. Diffs - configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION Diff: http://reviews.gem5.org/r/2669/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2665: sim: Reuse the same limit_event in simulate()
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2665/ --- Review request for Default. Repository: gem5 Description --- Changeset 10706:e77f25583997 --- sim: Reuse the same limit_event in simulate() This patch accomplishes two things: 1. Makes simulate()'s GlobalSimLoopExitEvent a singleton reused across calls. This is slightly more efficient than recreating it every time. 2. Gives callers to simulate() (especially other simulators) a foolproof way of knowing that the simulation period ended successfully by hitting the limit event. They can call getLimitEvent() and compare it to the return value of simulate(). This change was motivated by an ongoing effort to integrate gem5 and SST, with SST as the master sim and gem5 as the slave sim. Diffs - src/sim/sim_events.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.hh c6cb94a14fea4c59780d73d1623d7031bcede6af src/sim/simulate.cc c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2665/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2667: ext: Add SST connector
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2667/ --- Review request for Default. Repository: gem5 Description --- Changeset 10708:344bc6b7203d --- ext: Add SST connector This patch adds a connector that allows gem5 to be used as a component in SST (Structural Simulation Toolkit, sst-simulator.org). At a high level, this allows memory traffic to pass between the two simulators. SST Links are roughly analogous to gem5 Ports, although Links do not have a notion of master and slave. This distinction is important to gem5, so when connecting a gem5 CPU to an SST cache, an ExternalSlave must be used, and similarly when connecting the memory side of SST cache to a gem5 port (for memory - I/O), an ExternalMaster must be used. These connectors handle the administrative aspects of gem5 (initialization, simulation, shutdown) as well as translating SST's MemEvents into gem5 Packets and vice-versa. Diffs - ext/sst/ExtMaster.hh PRE-CREATION ext/sst/ExtMaster.cc PRE-CREATION ext/sst/ExtSlave.hh PRE-CREATION ext/sst/ExtSlave.cc PRE-CREATION ext/sst/LICENSE PRE-CREATION ext/sst/Makefile PRE-CREATION ext/sst/README PRE-CREATION ext/sst/gem5.hh PRE-CREATION ext/sst/gem5.cc PRE-CREATION ext/sst/libgem5.cc PRE-CREATION Diff: http://reviews.gem5.org/r/2667/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Review Request 2668: config: Support full-system with SST's memory system
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2668/ --- Review request for Default. Repository: gem5 Description --- Changeset 10709:a3b771cd744c --- config: Support full-system with SST's memory system This patch adds an example configuration in ext/sst/tests/ that allows an SST/gem5 instance to simulate a 4-core AArch64 system with SST's memHierarchy components providing all the caches and memories. Diffs - configs/common/CacheConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/FSConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/MemConfig.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/common/Options.py c6cb94a14fea4c59780d73d1623d7031bcede6af configs/example/fs.py c6cb94a14fea4c59780d73d1623d7031bcede6af ext/sst/tests/test6_arm_4c.py PRE-CREATION src/dev/arm/RealView.py c6cb94a14fea4c59780d73d1623d7031bcede6af src/mem/ExternalSlave.py c6cb94a14fea4c59780d73d1623d7031bcede6af Diff: http://reviews.gem5.org/r/2668/diff/ Testing --- Thanks, Curtis Dunham ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: config: add --root-device machine parameter
changeset 71c40e5c8bd4 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=71c40e5c8bd4
description:
config: add --root-device machine parameter
In case /dev/sda1 is not actually the boot partition for an image,
we can override it on the command line or in a benchmark definition.
diffstat:
configs/common/Benchmarks.py | 9 -
configs/common/FSConfig.py | 3 ++-
configs/common/Options.py| 2 ++
configs/example/fs.py| 9 ++---
4 files changed, 18 insertions(+), 5 deletions(-)
diffs (81 lines):
diff -r b5e5068fcb26 -r 71c40e5c8bd4 configs/common/Benchmarks.py
--- a/configs/common/Benchmarks.py Mon Feb 16 03:32:58 2015 -0500
+++ b/configs/common/Benchmarks.py Fri Jan 16 14:12:03 2015 -0600
@@ -31,10 +31,11 @@
from m5.defines import buildEnv
class SysConfig:
-def __init__(self, script=None, mem=None, disk=None):
+def __init__(self, script=None, mem=None, disk=None, rootdev=None):
self.scriptname = script
self.diskname = disk
self.memsize = mem
+self.root = rootdev
def script(self):
if self.scriptname:
@@ -62,6 +63,12 @@
buildEnv['TARGET_ISA']
exit(1)
+def rootdev(self):
+if self.root:
+return self.root
+else:
+return '/dev/sda1'
+
# Benchmarks are defined as a key in a dict which is a list of SysConfigs
# The first defined machine is the test system, the others are driving systems
diff -r b5e5068fcb26 -r 71c40e5c8bd4 configs/common/FSConfig.py
--- a/configs/common/FSConfig.pyMon Feb 16 03:32:58 2015 -0500
+++ b/configs/common/FSConfig.pyFri Jan 16 14:12:03 2015 -0600
@@ -57,6 +57,7 @@
def fillInCmdline(mdesc, template, **kwargs):
kwargs.setdefault('disk', mdesc.disk())
+kwargs.setdefault('rootdev', mdesc.rootdev())
kwargs.setdefault('mem', mdesc.mem())
kwargs.setdefault('script', mdesc.script())
return template % kwargs
@@ -279,7 +280,7 @@
if not cmdline:
cmdline = 'earlyprintk=pl011,0x1c09 console=ttyAMA0 ' + \
'lpj=19988480 norandmaps rw loglevel=8 ' + \
- 'mem=%(mem)s root=/dev/sda1'
+ 'mem=%(mem)s root=%(rootdev)s'
self.realview.setupBootLoader(self.membus, self, binary)
self.gic_cpu_addr = self.realview.gic.cpu_addr
diff -r b5e5068fcb26 -r 71c40e5c8bd4 configs/common/Options.py
--- a/configs/common/Options.py Mon Feb 16 03:32:58 2015 -0500
+++ b/configs/common/Options.py Fri Jan 16 14:12:03 2015 -0600
@@ -274,6 +274,8 @@
# Disk Image Options
parser.add_option(--disk-image, action=store, type=string,
default=None,
help=Path to the disk image to use.)
+parser.add_option(--root-device, action=store, type=string,
default=None,
+ help=OS device name for root partition)
# Command line options
parser.add_option(--command-line, action=store, type=string,
diff -r b5e5068fcb26 -r 71c40e5c8bd4 configs/example/fs.py
--- a/configs/example/fs.py Mon Feb 16 03:32:58 2015 -0500
+++ b/configs/example/fs.py Fri Jan 16 14:12:03 2015 -0600
@@ -313,10 +313,13 @@
sys.exit(1)
else:
if options.dual:
-bm = [SysConfig(disk=options.disk_image, mem=options.mem_size),
- SysConfig(disk=options.disk_image, mem=options.mem_size)]
+bm = [SysConfig(disk=options.disk_image, rootdev=options.root_device,
+mem=options.mem_size),
+ SysConfig(disk=options.disk_image, rootdev=options.root_device,
+mem=options.mem_size)]
else:
-bm = [SysConfig(disk=options.disk_image, mem=options.mem_size)]
+bm = [SysConfig(disk=options.disk_image, rootdev=options.root_device,
+mem=options.mem_size)]
np = options.num_cpus
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: sim: prioritize async events; prevent starvation
changeset 3bfbaefa3844 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3bfbaefa3844
description:
sim: prioritize async events; prevent starvation
If a time quantum event is the only one in the queue, async
events (Ctrl-C, I/O, etc.) will never be processed.
So process them first.
diffstat:
src/sim/simulate.cc | 21 ++---
1 files changed, 10 insertions(+), 11 deletions(-)
diffs (51 lines):
diff -r aae98c1cf4a0 -r 3bfbaefa3844 src/sim/simulate.cc
--- a/src/sim/simulate.cc Tue Feb 03 14:25:27 2015 -0500
+++ b/src/sim/simulate.cc Fri Dec 19 15:32:34 2014 -0600
@@ -192,37 +192,36 @@
assert(curTick() = eventq-nextTick()
event scheduled in the past);
-Event *exit_event = eventq-serviceOne();
-if (exit_event != NULL) {
-return exit_event;
-}
-
if (async_event testAndClearAsyncEvent()) {
// Take the event queue lock in case any of the service
// routines want to schedule new events.
std::lock_guardEventQueue lock(*eventq);
-async_event = false;
if (async_statdump || async_statreset) {
Stats::schedStatEvent(async_statdump, async_statreset);
async_statdump = false;
async_statreset = false;
}
+if (async_io) {
+async_io = false;
+pollQueue.service();
+}
+
if (async_exit) {
async_exit = false;
exitSimLoop(user interrupt received);
}
-if (async_io) {
-async_io = false;
-pollQueue.service();
-}
-
if (async_exception) {
async_exception = false;
return NULL;
}
}
+
+Event *exit_event = eventq-serviceOne();
+if (exit_event != NULL) {
+return exit_event;
+}
}
// not reached... only exit is return on SimLoopExitEvent
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: base: add an accessor and operators ==, != to ...
changeset d95e81d44e36 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d95e81d44e36
description:
base: add an accessor and operators ==,!= to address ranges
diffstat:
src/base/addr_range.hh | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diffs (38 lines):
diff -r 5935ab1ddd7a -r d95e81d44e36 src/base/addr_range.hh
--- a/src/base/addr_range.hhTue Feb 03 14:25:55 2015 -0500
+++ b/src/base/addr_range.hhTue Feb 03 14:25:58 2015 -0500
@@ -227,6 +227,11 @@
Addr start() const { return _start; }
/**
+ * Get the end address of the range.
+ */
+Addr end() const { return _end; }
+
+/**
* Get a string representation of the range. This could
* alternatively be implemented as a operator, but at the moment
* that seems like overkill.
@@ -363,6 +368,22 @@
return intlvMatch r.intlvMatch;
}
+bool operator==(const AddrRange r) const
+{
+if (_start!= r._start)return false;
+if (_end != r._end) return false;
+if (intlvBits != r.intlvBits) return false;
+if (intlvBits != 0) {
+if (intlvHighBit != r.intlvHighBit) return false;
+if (intlvMatch != r.intlvMatch) return false;
+}
+return true;
+}
+
+bool operator!=(const AddrRange r) const
+{
+return !(*this == r);
+}
#endif // SWIG
};
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: sim: fix reference counting of PythonEvent
changeset a0dab21e422f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a0dab21e422f
description:
sim: fix reference counting of PythonEvent
When gem5 is a slave to another simulator and the Python is only used
to initialize the configuration (and not perform actual simulation), a
debug start (--debug-start) event will get freed during or immediately
after the initial Python frame's execution rather than remaining in the
event queue. This tricky patch fixes the GC issue causing this.
diffstat:
src/python/swig/event.i| 4
src/python/swig/pyevent.cc | 8
src/python/swig/pyevent.hh | 5 +++--
3 files changed, 11 insertions(+), 6 deletions(-)
diffs (56 lines):
diff -r 87f7b5a07584 -r a0dab21e422f src/python/swig/event.i
--- a/src/python/swig/event.i Thu Jan 22 05:01:31 2015 -0500
+++ b/src/python/swig/event.i Tue Dec 23 11:51:40 2014 -0600
@@ -71,6 +71,10 @@
}
}
+%typemap(out) PythonEvent* {
+ result-object = $result = SWIG_NewPointerObj(SWIG_as_voidptr(result),
SWIGTYPE_p_PythonEvent, SWIG_POINTER_NEW);
+}
+
%ignore EventQueue::schedule;
%ignore EventQueue::deschedule;
diff -r 87f7b5a07584 -r a0dab21e422f src/python/swig/pyevent.cc
--- a/src/python/swig/pyevent.ccThu Jan 22 05:01:31 2015 -0500
+++ b/src/python/swig/pyevent.ccTue Dec 23 11:51:40 2014 -0600
@@ -34,10 +34,10 @@
#include sim/async.hh
#include sim/eventq.hh
-PythonEvent::PythonEvent(PyObject *obj, Priority priority)
-: Event(priority), object(obj)
+PythonEvent::PythonEvent(PyObject *code, Priority priority)
+: Event(priority), eventCode(code)
{
-if (object == NULL)
+if (code == NULL)
panic(Passed in invalid object);
}
@@ -49,7 +49,7 @@
PythonEvent::process()
{
PyObject *args = PyTuple_New(0);
-PyObject *result = PyObject_Call(object, args, NULL);
+PyObject *result = PyObject_Call(eventCode, args, NULL);
Py_DECREF(args);
if (result) {
diff -r 87f7b5a07584 -r a0dab21e422f src/python/swig/pyevent.hh
--- a/src/python/swig/pyevent.hhThu Jan 22 05:01:31 2015 -0500
+++ b/src/python/swig/pyevent.hhTue Dec 23 11:51:40 2014 -0600
@@ -37,9 +37,10 @@
class PythonEvent : public Event
{
private:
-PyObject *object;
+PyObject *eventCode; // PyObject to call to perform event
+ public:
+PyObject *object;// PyObject wrapping this PythonEvent
- public:
PythonEvent(PyObject *obj, Event::Priority priority);
~PythonEvent();
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: arm: Add stats to table walker
changeset b7bc5b1084a4 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b7bc5b1084a4
description:
arm: Add stats to table walker
This patch adds table walker stats for:
- Walk events
- Instruction vs Data
- Page size histogram
- Wait time and service time histograms
- Pending requests histogram (per cycle) - measures dist. of L
(p(1..) = how often busy, p(0) = how often idle)
- Squashes, before starting and after completion
diffstat:
src/arch/arm/table_walker.cc | 186 ++-
src/arch/arm/table_walker.hh | 31 +++
src/dev/dma_device.cc| 12 ++-
src/dev/dma_device.hh|4 +-
4 files changed, 225 insertions(+), 8 deletions(-)
diffs (truncated from 476 to 300 lines):
diff -r 74834c49fbbe -r b7bc5b1084a4 src/arch/arm/table_walker.cc
--- a/src/arch/arm/table_walker.cc Tue Dec 23 09:31:18 2014 -0500
+++ b/src/arch/arm/table_walker.cc Tue Dec 23 09:31:18 2014 -0500
@@ -60,6 +60,8 @@
stage2Mmu(NULL), isStage2(p-is_stage2), tlb(NULL),
currState(NULL), pending(false), masterId(p-sys-getMasterId(name())),
numSquashable(p-num_squash_per_cycle),
+ pendingReqs(0),
+ pendingChangeTick(curTick()),
doL1DescEvent(this), doL2DescEvent(this),
doL0LongDescEvent(this), doL1LongDescEvent(this),
doL2LongDescEvent(this),
doL3LongDescEvent(this),
@@ -151,6 +153,7 @@
if (params()-sys-isTimingMode() currState) {
delete currState;
currState = NULL;
+pendingChange();
}
}
@@ -170,6 +173,8 @@
bool secure, TLB::ArmTranslationType tranType)
{
assert(!(_functional _timing));
+++statWalks;
+
WalkerState *savedCurrState = NULL;
if (!currState !_functional) {
@@ -196,10 +201,13 @@
// this fault to re-execute the faulting instruction which should clean
// up everything.
if (currState-vaddr_tainted == _req-getVaddr()) {
+++statSquashedBefore;
return std::make_sharedReExec();
}
}
+pendingChange();
+currState-startTime = curTick();
currState-tc = _tc;
currState-aarch64 = opModeIs64(currOpMode(_tc));
currState-el = currEL(_tc);
@@ -261,6 +269,8 @@
currState-isFetch = (currState-mode == TLB::Execute);
currState-isWrite = (currState-mode == TLB::Write);
+statRequestOrigin[REQUESTED][currState-isFetch]++;
+
// We only do a second stage of translation if we're not secure, or in
// hyp mode, the second stage MMU is enabled, and this table walker
// instance is the first stage.
@@ -280,6 +290,10 @@
currState-userTable = true;
currState-xnTable = false;
currState-pxnTable = false;
+
+++statWalksLongDescriptor;
+} else {
+++statWalksShortDescriptor;
}
if (!currState-timing) {
@@ -303,8 +317,10 @@
if (pending || pendingQueue.size()) {
pendingQueue.push_back(currState);
currState = NULL;
+pendingChange();
} else {
pending = true;
+pendingChange();
if (currState-aarch64)
return processWalkAArch64();
else if (long_desc_format)
@@ -321,6 +337,7 @@
{
assert(!currState);
assert(pendingQueue.size());
+pendingChange();
currState = pendingQueue.front();
ExceptionLevel target_el = EL0;
@@ -372,6 +389,7 @@
(currState-transState-squashed() || te)) {
pendingQueue.pop_front();
num_squashed++;
+statSquashedBefore++;
DPRINTF(TLB, Squashing table walk for address %#x\n,
currState-vaddr_tainted);
@@ -383,6 +401,7 @@
currState-req, currState-tc, currState-mode);
} else {
// translate the request now that we know it will work
+statWalkServiceTime.sample(curTick() - currState-startTime);
tlb-translateTiming(currState-req, currState-tc,
currState-transState, currState-mode);
@@ -402,8 +421,9 @@
currState = NULL;
}
}
+pendingChange();
-// if we've still got pending translations schedule more work
+// if we still have pending translations, schedule more work
nextWalk(tc);
currState = NULL;
}
@@ -420,6 +440,8 @@
currState-vaddr_tainted, currState-ttbcr,
mbits(currState-vaddr, 31,
32 -
currState-ttbcr.n));
+statWalkWaitTime.sample(curTick() - currState-startTime);
+
if (currState-ttbcr.n == 0 || !mbits(currState-vaddr, 31,
32 - currState-ttbcr.n)) {
DPRINTF(TLB, - Selecting TTBR0\n);
@@ -511,6 +533,8 @@
DPRINTF(TLB, Beginning table walk for address %#x, TTBCR: %#x\n,
currState-vaddr_tainted, currState-ttbcr);
+
[gem5-dev] changeset in gem5: mem: Hide WriteInvalidate requests from prefe...
changeset 7982e539d003 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=7982e539d003
description:
mem: Hide WriteInvalidate requests from prefetchers
Without this tweak, a prefetcher will happily prefetch data that will
promptly be invalidated and overwritten by a WriteInvalidate.
diffstat:
src/mem/cache/prefetch/base.cc | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diffs (21 lines):
diff -r 00965520c9f5 -r 7982e539d003 src/mem/cache/prefetch/base.cc
--- a/src/mem/cache/prefetch/base.ccTue Dec 23 09:31:18 2014 -0500
+++ b/src/mem/cache/prefetch/base.ccTue Dec 23 09:31:19 2014 -0500
@@ -83,7 +83,8 @@
{
Addr addr = pkt-getAddr();
bool fetch = pkt-req-isInstFetch();
-bool read= pkt-isRead();
+bool read = pkt-isRead();
+bool inv = pkt-isInvalidate();
bool is_secure = pkt-isSecure();
if (pkt-req-isUncacheable()) return false;
@@ -91,6 +92,7 @@
if (!fetch !onData) return false;
if (!fetch read !onRead) return false;
if (!fetch !read !onWrite) return false;
+if (!fetch !read inv) return false;
if (onMiss) {
return !inCache(addr, is_secure)
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: mem: Support WriteInvalidate (again)
changeset d1e1e851 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d1e1e851
description:
mem: Support WriteInvalidate (again)
This patch takes a clean-slate approach to providing WriteInvalidate
(write streaming, full cache line writes without first reading)
support.
Unlike the prior attempt, which took an aggressive approach of directly
writing into the cache before handling the coherence actions, this
approach follows the existing cache flows as closely as possible.
diffstat:
src/mem/abstract_mem.cc | 9 -
src/mem/cache/cache_impl.hh | 66
src/mem/packet.hh | 45 --
3 files changed, 85 insertions(+), 35 deletions(-)
diffs (237 lines):
diff -r c04dc66e4316 -r d1e1e851 src/mem/abstract_mem.cc
--- a/src/mem/abstract_mem.cc Tue Dec 02 06:08:17 2014 -0500
+++ b/src/mem/abstract_mem.cc Tue Dec 02 06:08:19 2014 -0500
@@ -379,6 +379,13 @@
bytesRead[pkt-req-masterId()] += pkt-getSize();
if (pkt-req-isInstFetch())
bytesInstRead[pkt-req-masterId()] += pkt-getSize();
+} else if (pkt-isInvalidate()) {
+// no need to do anything
+// this clause is intentionally before the write clause: the only
+// transaction that is both a write and an invalidate is
+// WriteInvalidate, and for the sake of consistency, it does not
+// write to memory. in a cacheless system, there are no WriteInv's
+// because the Write - WriteInvalidate rewrite happens in the cache.
} else if (pkt-isWrite()) {
if (writeOK(pkt)) {
if (pmemAddr) {
@@ -391,8 +398,6 @@
numWrites[pkt-req-masterId()]++;
bytesWritten[pkt-req-masterId()] += pkt-getSize();
}
-} else if (pkt-isInvalidate()) {
-// no need to do anything
} else {
panic(unimplemented);
}
diff -r c04dc66e4316 -r d1e1e851 src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh Tue Dec 02 06:08:17 2014 -0500
+++ b/src/mem/cache/cache_impl.hh Tue Dec 02 06:08:19 2014 -0500
@@ -70,7 +70,7 @@
: BaseCache(p),
tags(dynamic_castTagStore*(p-tags)),
prefetcher(p-prefetcher),
- doFastWrites(false),
+ doFastWrites(true),
prefetchOnAccess(p-prefetch_on_access)
{
tempBlock = new BlkType();
@@ -167,7 +167,10 @@
// isWrite() will be true for them
if (pkt-cmd == MemCmd::SwapReq) {
cmpAndSwap(blk, pkt);
-} else if (pkt-isWrite()) {
+} else if (pkt-isWrite()
+ (!pkt-isWriteInvalidate() || isTopLevel)) {
+assert(blk-isWritable());
+// Write or WriteInvalidate at the first cache with block in Exclusive
if (blk-checkWrite(pkt)) {
pkt-writeDataToBlock(blk-data, blkSize);
}
@@ -176,6 +179,8 @@
// appended themselves to this cache before knowing the store
// will fail.
blk-status |= BlkDirty;
+DPRINTF(Cache, %s for %s address %x size %d (write)\n, __func__,
+pkt-cmdString(), pkt-getAddr(), pkt-getSize());
} else if (pkt-isRead()) {
if (pkt-isLLSC()) {
blk-trackLoadLocked(pkt);
@@ -229,13 +234,15 @@
}
}
} else {
-// Not a read or write... must be an upgrade. it's OK
-// to just ack those as long as we have an exclusive
-// copy at this level.
-assert(pkt-isUpgrade());
+// Upgrade or WriteInvalidate at a different cache than received it.
+// Since we have it Exclusively (E or M), we ack then invalidate.
+assert(pkt-isUpgrade() ||
+ (pkt-isWriteInvalidate() !isTopLevel));
assert(blk != tempBlock);
tags-invalidate(blk);
blk-invalidate();
+DPRINTF(Cache, %s for %s address %x size %d (invalidation)\n,
+__func__, pkt-cmdString(), pkt-getAddr(), pkt-getSize());
}
}
@@ -742,6 +749,8 @@
// where the determination the StoreCond fails is delayed due to
// all caches not being on the same local bus.
cmd = MemCmd::SCUpgradeFailReq;
+} else if (cpu_pkt-isWriteInvalidate()) {
+cmd = cpu_pkt-cmd;
} else {
// block is invalid
cmd = needsExclusive ? MemCmd::ReadExReq : MemCmd::ReadReq;
@@ -843,6 +852,14 @@
if (bus_pkt-isError()) {
pkt-makeAtomicResponse();
pkt-copyError(bus_pkt);
+} else if (pkt-isWriteInvalidate()) {
+// note the use of pkt, not bus_pkt here.
+if (isTopLevel) {
+blk = handleFill(pkt, blk, writebacks);
+satisfyCpuSideRequest(pkt, blk);
+} else if (blk) {
+satisfyCpuSideRequest(pkt, blk);
+}
[gem5-dev] changeset in gem5: mem: Remove WriteInvalidate support
changeset c04dc66e4316 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=c04dc66e4316
description:
mem: Remove WriteInvalidate support
Prepare for a different implementation following in the next patch
diffstat:
src/mem/cache/base.hh |1 -
src/mem/cache/blk.hh|3 -
src/mem/cache/cache_impl.hh | 189 ---
src/mem/cache/mshr.cc | 25 +
src/mem/cache/mshr.hh | 18
5 files changed, 25 insertions(+), 211 deletions(-)
diffs (truncated from 469 to 300 lines):
diff -r 7c4f1d0a8cff -r c04dc66e4316 src/mem/cache/base.hh
--- a/src/mem/cache/base.hh Tue Dec 02 06:08:15 2014 -0500
+++ b/src/mem/cache/base.hh Tue Dec 02 06:08:17 2014 -0500
@@ -94,7 +94,6 @@
Blocked_NoMSHRs = MSHRQueue_MSHRs,
Blocked_NoWBBuffers = MSHRQueue_WriteBuffer,
Blocked_NoTargets,
-Blocked_PendingWriteInvalidate,
NUM_BLOCKED_CAUSES
};
diff -r 7c4f1d0a8cff -r c04dc66e4316 src/mem/cache/blk.hh
--- a/src/mem/cache/blk.hh Tue Dec 02 06:08:15 2014 -0500
+++ b/src/mem/cache/blk.hh Tue Dec 02 06:08:17 2014 -0500
@@ -73,9 +73,6 @@
BlkHWPrefetched = 0x20,
/** block holds data from the secure memory space */
BlkSecure = 0x40,
-/** can the block transition to E? (hasn't been shared with another cache)
- * used to close a timing gap when handling WriteInvalidate packets */
-BlkCanGoExclusive = 0x80
};
/**
diff -r 7c4f1d0a8cff -r c04dc66e4316 src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh Tue Dec 02 06:08:15 2014 -0500
+++ b/src/mem/cache/cache_impl.hh Tue Dec 02 06:08:17 2014 -0500
@@ -70,7 +70,7 @@
: BaseCache(p),
tags(dynamic_castTagStore*(p-tags)),
prefetcher(p-prefetcher),
- doFastWrites(true),
+ doFastWrites(false),
prefetchOnAccess(p-prefetch_on_access)
{
tempBlock = new BlkType();
@@ -321,20 +321,15 @@
pkt-getAddr(), pkt-isSecure() ? s : ns,
blk ? hit : miss, blk ? blk-print() : );
-// Writeback handling is special case. We can write the block
-// into the cache without having a writeable copy (or any copy at
-// all). Like writebacks, we write into the cache upon initial
-// receipt of a write-invalidate packets as well.
-if ((pkt-cmd == MemCmd::Writeback) ||
- ((pkt-cmd == MemCmd::WriteInvalidateReq) isTopLevel)) {
+// Writeback handling is special case. We can write the block into
+// the cache without having a writeable copy (or any copy at all).
+if (pkt-cmd == MemCmd::Writeback) {
assert(blkSize == pkt-getSize());
if (blk == NULL) {
// need to do a replacement
blk = allocateBlock(pkt-getAddr(), pkt-isSecure(), writebacks);
if (blk == NULL) {
-// no replaceable block available, give up.
-// Writeback will be forwarded to next level,
-// WriteInvalidate will be retried.
+// no replaceable block available: give up, fwd to next level.
incMissCount(pkt);
return false;
}
@@ -345,29 +340,16 @@
blk-status |= BlkSecure;
}
}
-if (pkt-cmd == MemCmd::Writeback) {
-blk-status |= BlkDirty;
-if (pkt-isSupplyExclusive()) {
-blk-status |= BlkWritable;
-}
-// nothing else to do; writeback doesn't expect response
-assert(!pkt-needsResponse());
-} else if (pkt-cmd == MemCmd::WriteInvalidateReq) {
-blk-status |= (BlkReadable | BlkDirty | BlkCanGoExclusive);
-blk-status = ~BlkWritable;
-++fastWrites;
+blk-status |= BlkDirty;
+if (pkt-isSupplyExclusive()) {
+blk-status |= BlkWritable;
}
+// nothing else to do; writeback doesn't expect response
+assert(!pkt-needsResponse());
std::memcpy(blk-data, pkt-getConstPtruint8_t(), blkSize);
DPRINTF(Cache, %s new state is %s\n, __func__, blk-print());
incHitCount(pkt);
return true;
-} else if ((pkt-cmd == MemCmd::WriteInvalidateReq) !isTopLevel) {
-if (blk != NULL) {
-assert(blk != tempBlock);
-tags-invalidate(blk);
-blk-invalidate();
-}
-return true;
} else if ((blk != NULL)
(pkt-needsExclusive() ? blk-isWritable()
: blk-isReadable())) {
@@ -550,18 +532,6 @@
bool needsResponse = pkt-needsResponse();
-if (pkt-cmd == MemCmd::WriteInvalidateReq) {
-if (!satisfied isTopLevel) {
-// access() tried to allocate a block but it could not; abort.
-setBlocked(Blocked_PendingWriteInvalidate);
-return false;
-}
-satisfied = false;
-// we need to
[gem5-dev] changeset in gem5: mem: have WriteInvalidate obsolete MSHRs
changeset f2f1dbfd505e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=f2f1dbfd505e
description:
mem: have WriteInvalidate obsolete MSHRs
Since WriteInvalidate directly writes into the cache, it can
create tricky timing interleavings with reads and writes to the
same cache line that haven't yet completed. This patch ensures
that these requests, when completed, don't overwrite the newer
data from the WriteInvalidate.
diffstat:
src/mem/cache/cache_impl.hh | 35 +++
src/mem/cache/mshr.cc | 5 +++--
src/mem/cache/mshr.hh | 11 +++
3 files changed, 45 insertions(+), 6 deletions(-)
diffs (116 lines):
diff -r e278fa3086b5 -r f2f1dbfd505e src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh Tue Sep 02 11:26:32 2014 +0100
+++ b/src/mem/cache/cache_impl.hh Wed Oct 29 23:18:24 2014 -0500
@@ -636,7 +636,20 @@
pkt = pf;
}
-if (mshr) {
+if (pkt (pkt-cmd == MemCmd::WriteInvalidateReq)) {
+// WriteInvalidates cannot coalesce with other requests, so
+// we cannot use an existing MSHR. If one exists, we mark it
+// as 'obsolete' so they don't modify the cache.
+if (mshr) {
+// Everything up to this point is obsolete, meaning
+// they should not modify the cache.
+DPRINTF(Cache, %s: marking MSHR obsolete in %s of %x\n,
+__func__, pkt-cmdString(), pkt-getAddr());
+
+mshr-markObsolete();
+}
+allocateMissBuffer(pkt, time, true);
+} else if (mshr) {
/// MSHR hit
/// @note writebacks will be checked in getNextMSHR()
/// for any conflicting requests to the same block
@@ -1077,7 +1090,10 @@
bool is_fill = !mshr-isForward
(pkt-isRead() || pkt-cmd == MemCmd::UpgradeResp);
-if (is_fill !is_error) {
+if (mshr-isObsolete()) {
+DPRINTF(Cache, %s: skipping cache fills; data for %s of %x
+is obsolete\n, __func__, pkt-cmdString(), pkt-getAddr());
+} else if (is_fill !is_error) {
DPRINTF(Cache, Block for addr %x being updated in Cache\n,
pkt-getAddr());
@@ -1113,8 +1129,19 @@
}
if (is_fill) {
-satisfyCpuSideRequest(target-pkt, blk,
- true, mshr-hasPostDowngrade());
+// Presently the only situation leading to 'obsolete'
+// data is when a WriteInvalidate blows away an already
+// pending/in-progress read. We don't want to overwrite
+// cache data in that case.
+if (mshr-isObsolete()) {
+DPRINTF(Cache, %s: skipping satisfyCpuSideRequest;
+data for %s of %x is obsolete\n,
+__func__, target-pkt-cmdString(),
+target-pkt-getAddr());
+} else {
+satisfyCpuSideRequest(target-pkt, blk,
+ true, mshr-hasPostDowngrade());
+}
// How many bytes past the first request is this one
int transfer_offset =
target-pkt-getOffset(blkSize) - initial_offset;
diff -r e278fa3086b5 -r f2f1dbfd505e src/mem/cache/mshr.cc
--- a/src/mem/cache/mshr.cc Tue Sep 02 11:26:32 2014 +0100
+++ b/src/mem/cache/mshr.cc Wed Oct 29 23:18:24 2014 -0500
@@ -62,8 +62,8 @@
using namespace std;
MSHR::MSHR() : readyTime(0), _isUncacheable(false), downstreamPending(false),
- pendingDirty(false), postInvalidate(false),
- postDowngrade(false), queue(NULL), order(0), addr(0), size(0),
+ pendingDirty(false), postInvalidate(false),
postDowngrade(false),
+ _isObsolete(false), queue(NULL), order(0), addr(0), size(0),
isSecure(false), inService(false), isForward(false),
threadNum(InvalidThreadID), data(NULL)
{
@@ -214,6 +214,7 @@
_isUncacheable = target-req-isUncacheable();
inService = false;
downstreamPending = false;
+_isObsolete = false;
threadNum = 0;
assert(targets.isReset());
// Don't know of a case where we would allocate a new MSHR for a
diff -r e278fa3086b5 -r f2f1dbfd505e src/mem/cache/mshr.hh
--- a/src/mem/cache/mshr.hh Tue Sep 02 11:26:32 2014 +0100
+++ b/src/mem/cache/mshr.hh Wed Oct 29 23:18:24 2014 -0500
@@ -89,6 +89,9 @@
/** Did we snoop a read while waiting for data? */
bool postDowngrade;
+/** Did we get WriteInvalidate'd (and therefore obsoleted)? */
+bool _isObsolete;
+
public:
class Target {
@@ -214,6 +217,8 @@
bool isUncacheable() const { return _isUncacheable; }
+bool isObsolete() const { return _isObsolete; }
[gem5-dev] changeset in gem5: mem: don't inhibit WriteInv's or defer snoops...
changeset 94d58056729f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=94d58056729f
description:
mem: don't inhibit WriteInv's or defer snoops on their MSHRs
WriteInvalidate semantics depend on the unconditional writeback
or they won't complete. Also, there's no point in deferring snoops
on their MSHRs, as they don't get new data at the end of their life
cycle the way other transactions do.
Add comment in the cache about a minor inefficiency re: WriteInvalidate.
diffstat:
src/mem/cache/cache_impl.hh | 10 +++---
src/mem/cache/mshr.cc | 27 +--
src/mem/cache/mshr.hh | 7 +++
3 files changed, 35 insertions(+), 9 deletions(-)
diffs (126 lines):
diff -r f2f1dbfd505e -r 94d58056729f src/mem/cache/cache_impl.hh
--- a/src/mem/cache/cache_impl.hh Wed Oct 29 23:18:24 2014 -0500
+++ b/src/mem/cache/cache_impl.hh Tue Oct 21 17:04:41 2014 -0500
@@ -345,7 +345,6 @@
blk-status |= BlkSecure;
}
}
-std::memcpy(blk-data, pkt-getPtruint8_t(), blkSize);
if (pkt-cmd == MemCmd::Writeback) {
blk-status |= BlkDirty;
if (pkt-isSupplyExclusive()) {
@@ -354,11 +353,11 @@
// nothing else to do; writeback doesn't expect response
assert(!pkt-needsResponse());
} else if (pkt-cmd == MemCmd::WriteInvalidateReq) {
-assert(blk-isReadable()); // implicitly checks for Valid bit also
-blk-status |= (BlkDirty | BlkCanGoExclusive);
+blk-status |= (BlkReadable | BlkDirty | BlkCanGoExclusive);
blk-status = ~BlkWritable;
++fastWrites;
}
+std::memcpy(blk-data, pkt-getPtruint8_t(), blkSize);
DPRINTF(Cache, %s new state is %s\n, __func__, blk-print());
incHitCount(pkt);
return true;
@@ -1517,6 +1516,11 @@
// there are cases (such as failed store conditionals or
// compare-and-swaps) where we'll demand an exclusive copy but
// end up not writing it.
+// Caveat: if a Read takes a value from a WriteInvalidate MSHR,
+// it will get marked Dirty even though it is Clean (once the
+// WriteInvalidate completes). This is due to insufficient meta-
+// data and overly presumptive interpretation of the inhibit flag.
+// The result is an unnecessary extra writeback.
if (pkt-memInhibitAsserted())
blk-status |= BlkDirty;
}
diff -r f2f1dbfd505e -r 94d58056729f src/mem/cache/mshr.cc
--- a/src/mem/cache/mshr.cc Wed Oct 29 23:18:24 2014 -0500
+++ b/src/mem/cache/mshr.cc Tue Oct 21 17:04:41 2014 -0500
@@ -62,10 +62,11 @@
using namespace std;
MSHR::MSHR() : readyTime(0), _isUncacheable(false), downstreamPending(false),
- pendingDirty(false), postInvalidate(false),
postDowngrade(false),
- _isObsolete(false), queue(NULL), order(0), addr(0), size(0),
- isSecure(false), inService(false), isForward(false),
- threadNum(InvalidThreadID), data(NULL)
+ pendingDirty(false), pendingClean(false),
+ postInvalidate(false), postDowngrade(false),
+ _isObsolete(false), queue(NULL), order(0), addr(0),
+ size(0), isSecure(false), inService(false),
+ isForward(false), threadNum(InvalidThreadID), data(NULL)
{
}
@@ -213,6 +214,7 @@
isForward = false;
_isUncacheable = target-req-isUncacheable();
inService = false;
+pendingClean = (target-cmd == MemCmd::WriteInvalidateReq);
downstreamPending = false;
_isObsolete = false;
threadNum = 0;
@@ -251,7 +253,8 @@
assert(pkt != NULL);
inService = true;
-pendingDirty = (targets.needsExclusive ||
+pendingDirty = ((targets.needsExclusive
+ (pkt-cmd != MemCmd::WriteInvalidateReq)) ||
(!pkt-sharedAsserted() pkt-memInhibitAsserted()));
postInvalidate = postDowngrade = false;
@@ -367,7 +370,12 @@
targets.add(cp_pkt, curTick(), _order, Target::FromSnoop,
downstreamPending targets.needsExclusive);
-if (isPendingDirty()) {
+// WriteInvalidates must writeback and should not be inhibited on
+// account of its snoops discovering MSHRs wanting exclusive access
+// to what it wrote. We don't want to push this check higher,
+// however, because we want to be sure to add an invalidating
+// Target::FromSnoop, above.
+if (isPendingDirty() (pkt-cmd != MemCmd::WriteInvalidateReq)) {
pkt-assertMemInhibit();
pkt-setSupplyExclusive();
}
@@ -375,6 +383,13 @@
if (pkt-needsExclusive()) {
// This transaction will take away our pending copy
postInvalidate = true;
+
+// Do not defer (i.e. return true) the snoop if the
[gem5-dev] changeset in gem5: scons: create dummy target to have SWIG gener...
changeset dc49b13b6f79 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=dc49b13b6f79
description:
scons: create dummy target to have SWIG generate C++ classes
scons build/arch/swig
diffstat:
src/SConscript | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diffs (91 lines):
diff -r d0365cc3d05f -r dc49b13b6f79 src/SConscript
--- a/src/SConscriptThu Oct 16 05:49:32 2014 -0400
+++ b/src/SConscriptThu Oct 16 05:49:33 2014 -0400
@@ -627,6 +627,10 @@
obj.swig_decl(code)
code.write(target[0].abspath)
+# dummy target for generated code
+# we start out with all the Source files so they get copied to build/*/ also.
+SWIG = env.Dummy('swig', [s.tnode for s in Source.get()])
+
# Generate all of the SimObject param C++ struct header files
params_hh_files = []
for name,simobj in sorted(sim_objects.iteritems()):
@@ -638,6 +642,7 @@
env.Command(hh_file, Value(name),
MakeAction(createSimObjectParamStruct, Transform(SO PARAM)))
env.Depends(hh_file, depends + extra_deps)
+env.Depends(SWIG, hh_file)
# Generate any needed param SWIG wrapper files
params_i_files = []
@@ -647,6 +652,7 @@
env.Command(i_file, Value(name),
MakeAction(createParamSwigWrapper, Transform(SW PARAM)))
env.Depends(i_file, depends)
+env.Depends(SWIG, i_file)
SwigSource('m5.internal', i_file)
# Generate all enum header files
@@ -658,17 +664,20 @@
env.Command(cc_file, Value(name),
MakeAction(createEnumStrings, Transform(ENUM STR)))
env.Depends(cc_file, depends + extra_deps)
+env.Depends(SWIG, cc_file)
Source(cc_file)
hh_file = File('enums/%s.hh' % name)
env.Command(hh_file, Value(name),
MakeAction(createEnumDecls, Transform(ENUMDECL)))
env.Depends(hh_file, depends + extra_deps)
+env.Depends(SWIG, hh_file)
i_file = File('python/m5/internal/enum_%s.i' % name)
env.Command(i_file, Value(name),
MakeAction(createEnumSwigWrapper, Transform(ENUMSWIG)))
env.Depends(i_file, depends + extra_deps)
+env.Depends(SWIG, i_file)
SwigSource('m5.internal', i_file)
# Generate SimObject SWIG wrapper files
@@ -706,6 +715,7 @@
init_file = '%s/%s_init.cc' % (dirname(cc_file), basename(cc_file))
env.Command(init_file, Value(swig.module),
MakeAction(makeEmbeddedSwigInit, Transform(EMBED SW)))
+env.Depends(SWIG, init_file)
Source(init_file, **swig.guards)
# Build all protocol buffers if we have got protoc and protobuf available
@@ -720,6 +730,7 @@
'--proto_path ${SOURCE.dir} $SOURCE',
Transform(PROTOC)))
+env.Depends(SWIG, [proto.cc_file, proto.hh_file])
# Add the C++ source file
Source(proto.cc_file, **proto.guards)
elif ProtoBuf.all:
@@ -816,10 +827,13 @@
n, compound, desc = flag
assert n == name
-env.Command('debug/%s.hh' % name, Value(flag),
+hh_file = 'debug/%s.hh' % name
+cc_file = 'debug/%s.cc' % name
+env.Command(hh_file, Value(flag),
MakeAction(makeDebugFlagHH, Transform(TRACING, 0)))
-env.Command('debug/%s.cc' % name, Value(flag),
+env.Command(cc_file, Value(flag),
MakeAction(makeDebugFlagCC, Transform(TRACING, 0)))
+env.Depends(SWIG, [hh_file, cc_file])
Source('debug/%s.cc' % name)
# Embed python files. All .py files that have been indicated by a
@@ -878,6 +892,7 @@
for source in PySource.all:
env.Command(source.cpp, source.tnode,
MakeAction(embedPyFile, Transform(EMBED PY)))
+env.Depends(SWIG, source.cpp)
Source(source.cpp, skip_no_python=True)
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: scons: Add --without-tcmalloc build option
changeset 1e2cf7b3e9d4 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1e2cf7b3e9d4
description:
scons: Add --without-tcmalloc build option
Disabling tcmalloc is required for valgrind's memcheck to work properly;
this option makes it easier to create such a build.
diffstat:
SConstruct | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diffs (39 lines):
diff -r 30b40ca619ba -r 1e2cf7b3e9d4 SConstruct
--- a/SConstructTue Aug 12 17:35:28 2014 -0500
+++ b/SConstructMon Sep 22 14:37:23 2014 -0500
@@ -186,6 +186,9 @@
AddLocalOption('--without-python', dest='without_python',
action='store_true',
help='Build without Python configuration support')
+AddLocalOption('--without-tcmalloc', dest='without_tcmalloc',
+ action='store_true',
+ help='Disable linking against tcmalloc')
termcap = get_termcap(GetOption('use_colors'))
@@ -973,15 +976,16 @@
conf.CheckLibWithHeader([None, 'rt'], [ 'time.h', 'signal.h' ], 'C',
'timer_create(CLOCK_MONOTONIC, NULL, NULL);')
-if conf.CheckLib('tcmalloc'):
-main.Append(CCFLAGS=main['TCMALLOC_CCFLAGS'])
-elif conf.CheckLib('tcmalloc_minimal'):
-main.Append(CCFLAGS=main['TCMALLOC_CCFLAGS'])
-else:
-print termcap.Yellow + termcap.Bold + \
- You can get a 12% performance improvement by installing tcmalloc \
- (libgoogle-perftools-dev package on Ubuntu or RedHat). + \
- termcap.Normal
+if not GetOption('without_tcmalloc'):
+if conf.CheckLib('tcmalloc'):
+main.Append(CCFLAGS=main['TCMALLOC_CCFLAGS'])
+elif conf.CheckLib('tcmalloc_minimal'):
+main.Append(CCFLAGS=main['TCMALLOC_CCFLAGS'])
+else:
+print termcap.Yellow + termcap.Bold + \
+ You can get a 12% performance improvement by \
+ installing tcmalloc (libgoogle-perftools-dev package \
+ on Ubuntu or RedHat). + termcap.Normal
if not have_posix_clock:
print Can't find library for POSIX clocks.
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: mem: Provide better diagnostic for unconnecte...
changeset 1f12c11d89b6 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1f12c11d89b6
description:
mem: Provide better diagnostic for unconnected port
When _masterPort is null, a message to that effect is
more helpful than a segfault.
diffstat:
src/mem/port.hh | 6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diffs (16 lines):
diff -r 6400a2ab4e22 -r 1f12c11d89b6 src/mem/port.hh
--- a/src/mem/port.hh Sat Sep 27 09:08:29 2014 -0400
+++ b/src/mem/port.hh Sat Sep 27 09:08:30 2014 -0400
@@ -404,7 +404,11 @@
/**
* Called by the owner to send a range change
*/
-void sendRangeChange() const { _masterPort-recvRangeChange(); }
+void sendRangeChange() const {
+if (!_masterPort)
+fatal(%s cannot sendRangeChange() without master port, name());
+_masterPort-recvRangeChange();
+}
/**
* Get a list of the non-overlapping address ranges the owner is
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: dev: Output invalid access size in IsaFake panic
changeset 85274f24c37a in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=85274f24c37a description: dev: Output invalid access size in IsaFake panic diffstat: src/dev/isa_fake.cc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines): diff -r 3dabe649f1df -r 85274f24c37a src/dev/isa_fake.cc --- a/src/dev/isa_fake.cc Sat Sep 27 09:08:32 2014 -0400 +++ b/src/dev/isa_fake.cc Sat Sep 27 09:08:33 2014 -0400 @@ -110,7 +110,7 @@ data = pkt-getuint8_t(); break; default: -panic(invalid access size!\n); +panic(invalid access size: %u\n, pkt-getSize()); } warn(Device %s accessed by write to address %#x size=%d data=%#x\n, name(), pkt-getAddr(), pkt-getSize(), data); ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: tests: automatically kill regressions that ta...
changeset fa66d9c5e180 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=fa66d9c5e180
description:
tests: automatically kill regressions that take too long
When GNU coreutils 'timeout' is available, limit each regression
simulation to 4 hours.
diffstat:
SConstruct | 5 +
tests/SConscript | 10 --
2 files changed, 13 insertions(+), 2 deletions(-)
diffs (49 lines):
diff -r b31580e27d1f -r fa66d9c5e180 SConstruct
--- a/SConstructSat Sep 20 17:17:45 2014 -0400
+++ b/SConstructMon Aug 25 14:32:00 2014 -0500
@@ -752,6 +752,11 @@
swig_flags=Split('-c++ -python -modern -templatereduce $_CPPINCFLAGS')
main.Append(SWIGFLAGS=swig_flags)
+# Check for 'timeout' from GNU coreutils. If present, regressions
+# will be run with a time limit.
+TIMEOUT_version = readCommand(['timeout', '--version'], exception=False)
+main['TIMEOUT'] = TIMEOUT_version and TIMEOUT_version.find('timeout') == 0
+
# filter out all existing swig scanners, they mess up the dependency
# stuff for some reason
scanners = []
diff -r b31580e27d1f -r fa66d9c5e180 tests/SConscript
--- a/tests/SConscript Sat Sep 20 17:17:45 2014 -0400
+++ b/tests/SConscript Mon Aug 25 14:32:00 2014 -0500
@@ -104,6 +104,10 @@
timeout = 15 * 60 # used to be a param, probably should be again
if env['BATCH']:
cmd = '%s -t %d %s' % (env['BATCH_CMD'], timeout, cmd)
+# The slowest regression (bzip2) requires ~2.8 hours;
+# 4 hours was chosen to be conservative.
+elif env['TIMEOUT']:
+cmd = 'timeout 4h %s' % cmd
# Create a default value for the status string, changed as needed
# based on the status.
@@ -152,7 +156,9 @@
# Consider it a failed test unless the exit status is 2
status_str = FAILED!
# gem5 did not terminate properly, so no need to check the output
-if signaled(status):
+if env['TIMEOUT'] and status == 124:
+status_str = TIMED-OUT!
+elif signaled(status):
print 'gem5 terminated with signal', signum(status)
if signum(status) in retry_signals:
# Consider the test incomplete; don't create a 'status' output.
@@ -192,7 +198,7 @@
# if the test failed make it red, if it passed make it green, and
# skip the punctuation
-if status == FAILED!:
+if status == FAILED! or status == TIMED-OUT!:
status = termcap.Red + status[:-1] + termcap.Normal + status[-1]
elif status == CHANGED!:
status = termcap.Yellow + status[:-1] + termcap.Normal + status[-1]
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: arm: support 16kb vm granules
changeset f40134eb3f85 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=f40134eb3f85
description:
arm: support 16kb vm granules
diffstat:
src/arch/arm/miscregs.hh | 26 -
src/arch/arm/table_walker.cc | 125 +-
src/arch/arm/table_walker.hh | 56 +-
3 files changed, 139 insertions(+), 68 deletions(-)
diffs (truncated from 363 to 300 lines):
diff -r 5169ebd26163 -r f40134eb3f85 src/arch/arm/miscregs.hh
--- a/src/arch/arm/miscregs.hh Wed Sep 03 07:42:29 2014 -0400
+++ b/src/arch/arm/miscregs.hh Tue May 27 11:00:56 2014 -0500
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2010-2013 ARM Limited
+ * Copyright (c) 2010-2014 ARM Limited
* All rights reserved
*
* The license below extends only to copyright in the software and shall
@@ -1715,6 +1715,30 @@
Bitfield20 tbi;
EndBitUnion(TTBCR)
+// Fields of TCR_EL{1,2,3} (mostly overlapping)
+// TCR_EL1 is natively 64 bits, the others are 32 bits
+BitUnion64(TCR)
+Bitfield5, 0 t0sz;
+Bitfield7 epd0; // EL1
+Bitfield9, 8 irgn0;
+Bitfield11, 10 orgn0;
+Bitfield13, 12 sh0;
+Bitfield15, 14 tg0;
+Bitfield18, 16 ps;
+Bitfield20 tbi; // EL2/EL3
+Bitfield21, 16 t1sz; // EL1
+Bitfield22 a1; // EL1
+Bitfield23 epd1; // EL1
+Bitfield25, 24 irgn1; // EL1
+Bitfield27, 26 orgn1; // EL1
+Bitfield29, 28 sh1; // EL1
+Bitfield31, 30 tg1; // EL1
+Bitfield34, 32 ips; // EL1
+Bitfield36 as; // EL1
+Bitfield37 tbi0; // EL1
+Bitfield38 tbi1; // EL1
+EndBitUnion(TCR)
+
BitUnion32(HTCR)
Bitfield2, 0 t0sz;
Bitfield9, 8 irgn0;
diff -r 5169ebd26163 -r f40134eb3f85 src/arch/arm/table_walker.cc
--- a/src/arch/arm/table_walker.cc Wed Sep 03 07:42:29 2014 -0400
+++ b/src/arch/arm/table_walker.cc Tue May 27 11:00:56 2014 -0500
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2010, 2012-2013 ARM Limited
+ * Copyright (c) 2010, 2012-2014 ARM Limited
* All rights reserved
*
* The license below extends only to copyright in the software and shall
@@ -220,18 +220,18 @@
case EL0:
case EL1:
currState-sctlr = currState-tc-readMiscReg(MISCREG_SCTLR_EL1);
-currState-ttbcr = currState-tc-readMiscReg(MISCREG_TCR_EL1);
+currState-tcr = currState-tc-readMiscReg(MISCREG_TCR_EL1);
break;
// @todo: uncomment this to enable Virtualization
// case EL2:
// assert(haveVirtualization);
// currState-sctlr =
currState-tc-readMiscReg(MISCREG_SCTLR_EL2);
- // currState-ttbcr = currState-tc-readMiscReg(MISCREG_TCR_EL2);
+ // currState-tcr = currState-tc-readMiscReg(MISCREG_TCR_EL2);
// break;
case EL3:
assert(haveSecurity);
currState-sctlr = currState-tc-readMiscReg(MISCREG_SCTLR_EL3);
-currState-ttbcr = currState-tc-readMiscReg(MISCREG_TCR_EL3);
+currState-tcr = currState-tc-readMiscReg(MISCREG_TCR_EL3);
break;
default:
panic(Invalid exception level);
@@ -625,8 +625,7 @@
currState-longDesc.lookupLevel = start_lookup_level;
currState-longDesc.aarch64 = false;
-currState-longDesc.largeGrain = false;
-currState-longDesc.grainSize = 12;
+currState-longDesc.grainSize = Grain4KB;
Event *event = start_lookup_level == L1 ? (Event *) doL1LongDescEvent
: (Event *) doL2LongDescEvent;
@@ -663,13 +662,18 @@
{
assert(currState-aarch64);
-DPRINTF(TLB, Beginning table walk for address %#llx, TTBCR: %#llx\n,
-currState-vaddr_tainted, currState-ttbcr);
+DPRINTF(TLB, Beginning table walk for address %#llx, TCR: %#llx\n,
+currState-vaddr_tainted, currState-tcr);
+
+static const GrainSize GrainMapDefault[] =
+ { Grain4KB, Grain64KB, Grain16KB, ReservedGrain };
+static const GrainSize GrainMap_EL1_tg1[] =
+ { ReservedGrain, Grain16KB, Grain4KB, Grain64KB };
// Determine TTBR, table size, granule size and phys. address range
Addr ttbr = 0;
int tsz = 0, ps = 0;
-bool large_grain = false;
+GrainSize tg = Grain4KB; // grain size computed from tg* field
bool fault = false;
switch (currState-el) {
case EL0:
@@ -678,44 +682,44 @@
case 0:
DPRINTF(TLB, - Selecting TTBR0 (AArch64)\n);
ttbr = currState-tc-readMiscReg(MISCREG_TTBR0_EL1);
-tsz = adjustTableSizeAArch64(64 - currState-ttbcr.t0sz);
-large_grain = currState-ttbcr.tg0;
+tsz = adjustTableSizeAArch64(64 - currState-tcr.t0sz);
+tg = GrainMapDefault[currState-tcr.tg0];
if (bits(currState-vaddr, 63, tsz) != 0x0 ||
-currState-ttbcr.epd0)
+
[gem5-dev] changeset in gem5: mem: Refactor assignment of Packet types
changeset 711eb0e64249 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=711eb0e64249
description:
mem: Refactor assignment of Packet types
Put the packet type swizzling (that is currently done in a lot of
places)
into a refineCommand() member function.
diffstat:
src/cpu/checker/cpu.cc | 5 +---
src/cpu/inorder/resources/cache_unit.cc | 14 +-
src/cpu/o3/lsq_unit.hh | 7 ++---
src/cpu/o3/lsq_unit_impl.hh | 9 ++
src/cpu/ozone/lw_lsq.hh | 5 +---
src/cpu/ozone/lw_lsq_impl.hh| 5 +---
src/cpu/simple/atomic.cc| 5 +--
src/cpu/simple/timing.cc| 15 +---
src/mem/packet.hh | 41 -
9 files changed, 54 insertions(+), 52 deletions(-)
diffs (223 lines):
diff -r 0b4d10f53c2d -r 711eb0e64249 src/cpu/checker/cpu.cc
--- a/src/cpu/checker/cpu.ccWed Sep 03 07:42:46 2014 -0400
+++ b/src/cpu/checker/cpu.ccTue May 13 12:20:48 2014 -0500
@@ -170,10 +170,7 @@
// Now do the access
if (fault == NoFault
!memReq-getFlags().isSet(Request::NO_ACCESS)) {
-PacketPtr pkt = new Packet(memReq,
- memReq-isLLSC() ?
- MemCmd::LoadLockedReq :
- MemCmd::ReadReq);
+PacketPtr pkt = Packet::createRead(memReq);
pkt-dataStatic(data);
diff -r 0b4d10f53c2d -r 711eb0e64249 src/cpu/inorder/resources/cache_unit.cc
--- a/src/cpu/inorder/resources/cache_unit.cc Wed Sep 03 07:42:46 2014 -0400
+++ b/src/cpu/inorder/resources/cache_unit.cc Tue May 13 12:20:48 2014 -0500
@@ -812,21 +812,11 @@
void
CacheUnit::buildDataPacket(CacheRequest *cache_req)
{
-// Check for LL/SC and if so change command
-if (cache_req-memReq-isLLSC() cache_req-pktCmd == MemCmd::ReadReq) {
-cache_req-pktCmd = MemCmd::LoadLockedReq;
-}
-
-if (cache_req-pktCmd == MemCmd::WriteReq) {
-cache_req-pktCmd =
-cache_req-memReq-isSwap() ? MemCmd::SwapReq :
-(cache_req-memReq-isLLSC() ? MemCmd::StoreCondReq
- : MemCmd::WriteReq);
-}
-
cache_req-dataPkt = new CacheReqPacket(cache_req,
cache_req-pktCmd,
cache_req-instIdx);
+cache_req-dataPkt-refineCommand(); // handle LL/SC, etc.
+
DPRINTF(InOrderCachePort, [slot:%i]: Slot marked for %x\n,
cache_req-getSlot(),
cache_req-dataPkt-getAddr());
diff -r 0b4d10f53c2d -r 711eb0e64249 src/cpu/o3/lsq_unit.hh
--- a/src/cpu/o3/lsq_unit.hhWed Sep 03 07:42:46 2014 -0400
+++ b/src/cpu/o3/lsq_unit.hhTue May 13 12:20:48 2014 -0500
@@ -776,8 +776,7 @@
// if we the cache is not blocked, do cache access
bool completedFirst = false;
-MemCmd command = req-isLLSC() ? MemCmd::LoadLockedReq : MemCmd::ReadReq;
-PacketPtr data_pkt = new Packet(req, command);
+PacketPtr data_pkt = Packet::createRead(req);
PacketPtr fst_data_pkt = NULL;
PacketPtr snd_data_pkt = NULL;
@@ -794,8 +793,8 @@
fst_data_pkt = data_pkt;
} else {
// Create the split packets.
-fst_data_pkt = new Packet(sreqLow, command);
-snd_data_pkt = new Packet(sreqHigh, command);
+fst_data_pkt = Packet::createRead(sreqLow);
+snd_data_pkt = Packet::createRead(sreqHigh);
fst_data_pkt-dataStatic(load_inst-memData);
snd_data_pkt-dataStatic(load_inst-memData + sreqLow-getSize());
diff -r 0b4d10f53c2d -r 711eb0e64249 src/cpu/o3/lsq_unit_impl.hh
--- a/src/cpu/o3/lsq_unit_impl.hh Wed Sep 03 07:42:46 2014 -0400
+++ b/src/cpu/o3/lsq_unit_impl.hh Tue May 13 12:20:48 2014 -0500
@@ -839,9 +839,6 @@
else
memcpy(inst-memData, storeQueue[storeWBIdx].data, req-getSize());
-MemCmd command =
-req-isSwap() ? MemCmd::SwapReq :
-(req-isLLSC() ? MemCmd::StoreCondReq : MemCmd::WriteReq);
PacketPtr data_pkt;
PacketPtr snd_data_pkt = NULL;
@@ -853,13 +850,13 @@
if (!TheISA::HasUnalignedMemAcc || !storeQueue[storeWBIdx].isSplit) {
// Build a single data packet if the store isn't split.
-data_pkt = new Packet(req, command);
+data_pkt = Packet::createWrite(req);
data_pkt-dataStatic(inst-memData);
data_pkt-senderState = state;
} else {
// Create two packets if the store is split in two.
-data_pkt = new Packet(sreqLow, command);
-snd_data_pkt = new Packet(sreqHigh, command);
+data_pkt = Packet::createWrite(sreqLow);
+snd_data_pkt = Packet::createWrite(sreqHigh);
data_pkt-dataStatic(inst-memData);
snd_data_pkt-dataStatic(inst-memData +
[gem5-dev] changeset in gem5: arm: use condition code registers for ARM ISA
changeset 8bee5f4edb92 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8bee5f4edb92
description:
arm: use condition code registers for ARM ISA
Analogous to ee049bf (for x86). Requires a bump of the checkpoint
version
and corresponding upgrader code to move the condition code register
values
to the new register file.
diffstat:
src/arch/arm/ccregs.hh| 85 +++
src/arch/arm/faults.cc| 18
src/arch/arm/insts/static_inst.cc | 5 +-
src/arch/arm/intregs.hh | 5 --
src/arch/arm/isa.cc | 14 +++---
src/arch/arm/isa.hh | 6 +-
src/arch/arm/isa/operands.isa | 54
src/arch/arm/miscregs.hh | 19
src/arch/arm/nativetrace.cc | 12 ++--
src/arch/arm/registers.hh | 14 --
src/arch/arm/utility.cc | 6 +-
src/cpu/o3/O3CPU.py | 2 +-
src/cpu/simple_thread.hh | 1 +
src/sim/serialize.hh | 2 +-
util/cpt_upgrader.py | 28
15 files changed, 184 insertions(+), 87 deletions(-)
diffs (truncated from 538 to 300 lines):
diff -r 85001c018d4c -r 8bee5f4edb92 src/arch/arm/ccregs.hh
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/src/arch/arm/ccregs.hhTue Apr 29 16:05:02 2014 -0500
@@ -0,0 +1,85 @@
+/*
+ * Copyright (c) 2014 ARM Limited
+ * All rights reserved
+ *
+ * The license below extends only to copyright in the software and shall
+ * not be construed as granting a license to any other intellectual
+ * property including but not limited to intellectual property relating
+ * to a hardware implementation of the functionality of the software
+ * licensed hereunder. You may use the software subject to the license
+ * terms below provided that you ensure that this notice is replicated
+ * unmodified and in its entirety in all distributions of the software,
+ * modified or unmodified, in source code or in binary form.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are
+ * met: redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer;
+ * redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution;
+ * neither the name of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * Authors: Curtis Dunham
+ */
+#ifndef __ARCH_ARM_CCREGS_HH__
+#define __ARCH_ARM_CCREGS_HH__
+
+namespace ArmISA
+{
+
+enum ccRegIndex {
+CCREG_NZ,
+CCREG_C,
+CCREG_V,
+CCREG_GE,
+CCREG_FP,
+CCREG_ZERO,
+NUM_CCREGS
+};
+
+const char * const ccRegName[NUM_CCREGS] = {
+nz,
+c,
+v,
+ge,
+fp,
+zero
+};
+
+enum ConditionCode {
+COND_EQ = 0,
+COND_NE, // 1
+COND_CS, // 2
+COND_CC, // 3
+COND_MI, // 4
+COND_PL, // 5
+COND_VS, // 6
+COND_VC, // 7
+COND_HI, // 8
+COND_LS, // 9
+COND_GE, // 10
+COND_LT, // 11
+COND_GT, // 12
+COND_LE, // 13
+COND_AL, // 14
+COND_UC // 15
+};
+
+}
+
+#endif // __ARCH_ARM_CCREGS_HH__
diff -r 85001c018d4c -r 8bee5f4edb92 src/arch/arm/faults.cc
--- a/src/arch/arm/faults.ccWed Sep 03 07:42:43 2014 -0400
+++ b/src/arch/arm/faults.ccTue Apr 29 16:05:02 2014 -0500
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2010, 2012-2013 ARM Limited
+ * Copyright (c) 2010, 2012-2014 ARM Limited
* All rights reserved
*
* The license below extends only to copyright in the software and shall
@@ -466,10 +466,10 @@
SCTLR sctlr = tc-readMiscReg(MISCREG_SCTLR);
SCR scr = tc-readMiscReg(MISCREG_SCR);
CPSR saved_cpsr = tc-readMiscReg(MISCREG_CPSR);
-saved_cpsr.nz = tc-readIntReg(INTREG_CONDCODES_NZ);
-saved_cpsr.c = tc-readIntReg(INTREG_CONDCODES_C);
-
[gem5-dev] changeset in gem5: sim: bump checkpoint version for multiple eve...
changeset 6cb378bad253 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=6cb378bad253
description:
sim: bump checkpoint version for multiple event queues
This patch adds a fix for older checkpoints before support for
multiple event queues were added in changeset 2cce74fe359e. The change
in checkpoint version should really hav ebeen part of the
aforementioned changeset.
diffstat:
src/sim/serialize.hh | 2 +-
util/cpt_upgrader.py | 7 +++
2 files changed, 8 insertions(+), 1 deletions(-)
diffs (36 lines):
diff -r d02872388224 -r 6cb378bad253 src/sim/serialize.hh
--- a/src/sim/serialize.hh Tue Aug 26 10:12:04 2014 -0400
+++ b/src/sim/serialize.hh Wed Feb 05 16:17:41 2014 -0600
@@ -58,7 +58,7 @@
* SimObject shouldn't cause the version number to increase, only changes to
* existing objects such as serializing/unserializing more state, changing
sizes
* of serialized arrays, etc. */
-static const uint64_t gem5CheckpointVersion = 0x000b;
+static const uint64_t gem5CheckpointVersion = 0x000c;
template class T
void paramOut(std::ostream os, const std::string name, const T param);
diff -r d02872388224 -r 6cb378bad253 util/cpt_upgrader.py
--- a/util/cpt_upgrader.py Tue Aug 26 10:12:04 2014 -0400
+++ b/util/cpt_upgrader.py Wed Feb 05 16:17:41 2014 -0600
@@ -569,6 +569,12 @@
else:
continue
+# The change between versions C and D is the addition of support for multiple
+# event queues, so for old checkpoints we must specify that there's only one.
+def from_B(cpt):
+cpt.set('Globals', 'numMainEventQueues', '1')
+
+
migrations = []
migrations.append(from_0)
migrations.append(from_1)
@@ -581,6 +587,7 @@
migrations.append(from_8)
migrations.append(from_9)
migrations.append(from_A)
+migrations.append(from_B)
verbose_print = False
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2327: arm: support 16kb vm granules
On Aug. 20, 2014, 5:39 p.m., Nilay Vaish wrote: While I am ok with the changes made, do you think it is possible to retain the Enum instead of using 12, 14 and 16? I think this should be fine. I'll update patch shortly. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2327/#review5285 --- On Aug. 18, 2014, 9:55 p.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2327/ --- (Updated Aug. 18, 2014, 9:55 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10288:3f7ff9a4c112 --- arm: support 16kb vm granules Diffs - src/arch/arm/miscregs.hh 79fde1c67ed8 src/arch/arm/table_walker.hh 79fde1c67ed8 src/arch/arm/table_walker.cc 79fde1c67ed8 Diff: http://reviews.gem5.org/r/2327/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: ext: disable PLY debugging
changeset a0d94ac7e004 in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=a0d94ac7e004 description: ext: disable PLY debugging Very rarely does anyone ever mess with PLY code, and when such a need arises, the developer can reenable this flag in their working tree. This will eliminate the generating LALR tables message during compilation and temporary parser.out file as well. diffstat: ext/ply/ply/yacc.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diffs (12 lines): diff -r 6270235e0585 -r a0d94ac7e004 ext/ply/ply/yacc.py --- a/ext/ply/ply/yacc.py Fri May 09 18:58:46 2014 -0400 +++ b/ext/ply/ply/yacc.py Wed Mar 19 19:18:43 2014 -0500 @@ -68,7 +68,7 @@ # Change these to modify the default behavior of yacc (if you wish) #- -yaccdebug = 1# Debugging mode. If set, yacc generates a +yaccdebug = 0# Debugging mode. If set, yacc generates a # a 'parser.out' file in the current directory debug_file = 'parser.out' # Default name of the debugging file ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: scons: Require SWIG = 2.0.4 and remove vecto...
changeset 6270235e0585 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=6270235e0585
description:
scons: Require SWIG = 2.0.4 and remove vector typemaps
SWIG commit fd666c1 (*) made it unnecessary for gem5 to have these
typemaps to handle Vector types.
*
https://github.com/swig/swig/commit/fd666c1440628a847793bbe1333c27dfa2f757f0
diffstat:
SConstruct | 13 +
src/python/m5/params.py | 20
2 files changed, 1 insertions(+), 32 deletions(-)
diffs (58 lines):
diff -r e40b35147270 -r 6270235e0585 SConstruct
--- a/SConstructWed Apr 23 05:18:30 2014 -0400
+++ b/SConstructFri May 09 18:58:46 2014 -0400
@@ -726,23 +726,12 @@
print 'Error determining SWIG version.'
Exit(1)
-min_swig_version = '1.3.34'
+min_swig_version = '2.0.4'
if compareVersions(swig_version[2], min_swig_version) 0:
print 'Error: SWIG version', min_swig_version, 'or newer required.'
print ' Installed version:', swig_version[2]
Exit(1)
-# Older versions of swig do not play well with more recent versions of
-# gcc due to assumptions on implicit includes (cstddef) and use of
-# namespaces
-if main['GCC'] and compareVersions(gcc_version, '4.6') 0 and \
-compareVersions(swig_version[2], '2') 0:
-print '\n' + termcap.Yellow + termcap.Bold + \
-'Warning: SWIG 1.x cause issues with gcc 4.6 and later.\n' + \
-termcap.Normal + \
-'Use SWIG 2.x to avoid assumptions on implicit includes\n' + \
-'and use of namespaces\n'
-
# Set up SWIG flags scanner
swig_flags=Split('-c++ -python -modern -templatereduce $_CPPINCFLAGS')
main.Append(SWIGFLAGS=swig_flags)
diff -r e40b35147270 -r 6270235e0585 src/python/m5/params.py
--- a/src/python/m5/params.py Wed Apr 23 05:18:30 2014 -0400
+++ b/src/python/m5/params.py Fri May 09 18:58:46 2014 -0400
@@ -299,26 +299,6 @@
ptype = self.ptype_str
cxx_type = self.ptype.cxx_type
-code('''\
-%typemap(in) std::vector $cxx_type ::value_type {
-if (SWIG_ConvertPtr($$input, (void **)$$1, $$1_descriptor, 0) == -1) {
-if (SWIG_ConvertPtr($$input, (void **)$$1,
-$$descriptor($cxx_type), 0) == -1) {
-return NULL;
-}
-}
-}
-
-%typemap(in) std::vector $cxx_type ::value_type * {
-if (SWIG_ConvertPtr($$input, (void **)$$1, $$1_descriptor, 0) == -1) {
-if (SWIG_ConvertPtr($$input, (void **)$$1,
-$$descriptor($cxx_type *), 0) == -1) {
-return NULL;
-}
-}
-}
-''')
-
code('%template(vector_$ptype) std::vector $cxx_type ;')
def cxx_predecls(self, code):
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: arm: cleanup ARM ISA definition
changeset badc31a41a87 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=badc31a41a87
description:
arm: cleanup ARM ISA definition
diffstat:
src/arch/arm/isa/insts/basic.isa | 34 --
src/arch/arm/isa/insts/insts.isa | 5 +
src/arch/arm/isa/templates/vfp64.isa | 16 +---
3 files changed, 2 insertions(+), 53 deletions(-)
diffs (91 lines):
diff -r a0d94ac7e004 -r badc31a41a87 src/arch/arm/isa/insts/basic.isa
--- a/src/arch/arm/isa/insts/basic.isa Wed Mar 19 19:18:43 2014 -0500
+++ /dev/null Thu Jan 01 00:00:00 1970 +
@@ -1,34 +0,0 @@
-// -*- mode:c++ -*-
-
-// Copyright (c) 2007-2008 The Florida State University
-// All rights reserved.
-//
-// Redistribution and use in source and binary forms, with or without
-// modification, are permitted provided that the following conditions are
-// met: redistributions of source code must retain the above copyright
-// notice, this list of conditions and the following disclaimer;
-// redistributions in binary form must reproduce the above copyright
-// notice, this list of conditions and the following disclaimer in the
-// documentation and/or other materials provided with the distribution;
-// neither the name of the copyright holders nor the names of its
-// contributors may be used to endorse or promote products derived from
-// this software without specific prior written permission.
-//
-// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-// AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-//
-// Authors: Stephen Hines
-
-// Declarations for execute() methods.
-def template BasicExecDeclare {{
-Fault execute(%(CPU_exec_context)s *, Trace::InstRecord *) const;
-}};
diff -r a0d94ac7e004 -r badc31a41a87 src/arch/arm/isa/insts/insts.isa
--- a/src/arch/arm/isa/insts/insts.isa Wed Mar 19 19:18:43 2014 -0500
+++ b/src/arch/arm/isa/insts/insts.isa Fri May 09 18:58:46 2014 -0400
@@ -1,6 +1,6 @@
// -*- mode:c++ -*-
-// Copyright (c) 2010-2012 ARM Limited
+// Copyright (c) 2010-2014 ARM Limited
// All rights reserved
//
// The license below extends only to copyright in the software and shall
@@ -40,9 +40,6 @@
//AArch64 instructions
##include aarch64.isa
-//Basic forms of various templates
-##include basic.isa
-
//Useful bits shared by memory instructions
##include mem.isa
diff -r a0d94ac7e004 -r badc31a41a87 src/arch/arm/isa/templates/vfp64.isa
--- a/src/arch/arm/isa/templates/vfp64.isa Wed Mar 19 19:18:43 2014 -0500
+++ b/src/arch/arm/isa/templates/vfp64.isa Fri May 09 18:58:46 2014 -0400
@@ -1,6 +1,6 @@
// -*- mode:c++ -*-
-// Copyright (c) 2012 ARM Limited
+// Copyright (c) 2012, 2014 ARM Limited
// All rights reserved
//
// The license below extends only to copyright in the software and shall
@@ -51,20 +51,6 @@
}
}};
-def template AA64FpRegRegOpConstructor {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst,
- IntRegIndex _dest, IntRegIndex _op1,
- VfpMicroMode mode)
-: %(base_class)s(%(mnemonic)s, machInst, %(op_class)s,
-_dest, _op1, mode)
-{
-%(constructor)s;
-for (int x = 0; x _numDestRegs; x++) {
-_srcRegIdx[_numSrcRegs++] = _destRegIdx[x];
-}
-}
-}};
-
def template AA64FpRegImmOpConstructor {{
inline %(class_name)s::%(class_name)s(ExtMachInst machInst,
IntRegIndex _dest, uint64_t _imm, VfpMicroMode mode)
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: arch: remove inline specifiers on all inst co...
changeset bbfa3152bdea in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=bbfa3152bdea
description:
arch: remove inline specifiers on all inst constrs, all ISAs
With (upcoming) separate compilation, they are useless. Only
link-time optimization could re-inline them, but ideally
feedback-directed optimization would choose to do so only for
profitable (i.e. common) instructions.
diffstat:
src/arch/alpha/isa/main.isa | 2 +-
src/arch/alpha/isa/mem.isa | 2 +-
src/arch/arm/isa/templates/basic.isa| 2 +-
src/arch/arm/isa/templates/branch.isa | 12
src/arch/arm/isa/templates/branch64.isa | 10
src/arch/arm/isa/templates/data64.isa | 20
src/arch/arm/isa/templates/mem.isa | 24 +-
src/arch/arm/isa/templates/mem64.isa| 2 +-
src/arch/arm/isa/templates/misc.isa | 36 ++--
src/arch/arm/isa/templates/misc64.isa | 4 +-
src/arch/arm/isa/templates/mult.isa | 4 +-
src/arch/arm/isa/templates/pred.isa | 6 ++--
src/arch/arm/isa/templates/vfp.isa | 8 +++---
src/arch/arm/isa/templates/vfp64.isa| 10
src/arch/mips/isa/formats/basic.isa | 2 +-
src/arch/mips/isa/formats/mem.isa | 2 +-
src/arch/power/isa/formats/basic.isa| 2 +-
src/arch/power/isa/formats/integer.isa | 6 ++--
src/arch/power/isa/formats/mem.isa | 2 +-
src/arch/sparc/isa/formats/basic.isa| 4 +-
src/arch/sparc/isa/formats/mem/blockmem.isa | 4 +-
src/arch/sparc/isa/formats/priv.isa | 2 +-
src/arch/x86/isa/formats/basic.isa | 2 +-
src/arch/x86/isa/macroop.isa| 2 +-
src/arch/x86/isa/microops/fpop.isa | 2 +-
src/arch/x86/isa/microops/ldstop.isa| 2 +-
src/arch/x86/isa/microops/limmop.isa| 2 +-
src/arch/x86/isa/microops/mediaop.isa | 4 +-
src/arch/x86/isa/microops/regop.isa | 4 +-
src/arch/x86/isa/microops/seqop.isa | 4 +-
src/arch/x86/isa/microops/specop.isa| 6 ++--
31 files changed, 97 insertions(+), 97 deletions(-)
diffs (truncated from 966 to 300 lines):
diff -r badc31a41a87 -r bbfa3152bdea src/arch/alpha/isa/main.isa
--- a/src/arch/alpha/isa/main.isa Fri May 09 18:58:46 2014 -0400
+++ b/src/arch/alpha/isa/main.isa Fri May 09 18:58:46 2014 -0400
@@ -314,7 +314,7 @@
// Basic instruction class constructor template.
def template BasicConstructor {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst)
+%(class_name)s::%(class_name)s(ExtMachInst machInst)
: %(base_class)s(%(mnemonic)s, machInst, %(op_class)s)
{
%(constructor)s;
diff -r badc31a41a87 -r bbfa3152bdea src/arch/alpha/isa/mem.isa
--- a/src/arch/alpha/isa/mem.isaFri May 09 18:58:46 2014 -0400
+++ b/src/arch/alpha/isa/mem.isaFri May 09 18:58:46 2014 -0400
@@ -155,7 +155,7 @@
}};
def template LoadStoreConstructor {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst)
+%(class_name)s::%(class_name)s(ExtMachInst machInst)
: %(base_class)s(%(mnemonic)s, machInst, %(op_class)s)
{
%(constructor)s;
diff -r badc31a41a87 -r bbfa3152bdea src/arch/arm/isa/templates/basic.isa
--- a/src/arch/arm/isa/templates/basic.isa Fri May 09 18:58:46 2014 -0400
+++ b/src/arch/arm/isa/templates/basic.isa Fri May 09 18:58:46 2014 -0400
@@ -73,7 +73,7 @@
}};
def template BasicConstructor64 {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst) :
%(base_class)s(%(mnemonic)s, machInst, %(op_class)s)
+%(class_name)s::%(class_name)s(ExtMachInst machInst) :
%(base_class)s(%(mnemonic)s, machInst, %(op_class)s)
{
%(constructor)s;
}
diff -r badc31a41a87 -r bbfa3152bdea src/arch/arm/isa/templates/branch.isa
--- a/src/arch/arm/isa/templates/branch.isa Fri May 09 18:58:46 2014 -0400
+++ b/src/arch/arm/isa/templates/branch.isa Fri May 09 18:58:46 2014 -0400
@@ -48,7 +48,7 @@
}};
def template BranchImmConstructor {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst,
+%(class_name)s::%(class_name)s(ExtMachInst machInst,
int32_t _imm)
: %(base_class)s(%(mnemonic)s, machInst, %(op_class)s, _imm)
{
@@ -81,7 +81,7 @@
}};
def template BranchImmCondConstructor {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst,
+%(class_name)s::%(class_name)s(ExtMachInst machInst,
int32_t _imm,
ConditionCode _condCode)
: %(base_class)s(%(mnemonic)s, machInst, %(op_class)s,
@@ -110,7 +110,7 @@
}};
def template BranchRegConstructor {{
-inline %(class_name)s::%(class_name)s(ExtMachInst machInst,
+
[gem5-dev] changeset in gem5: arm: add preliminary ISA splits for ARM arch
changeset a60405212dea in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a60405212dea
description:
arm: add preliminary ISA splits for ARM arch
diffstat:
src/arch/arm/isa/insts/insts.isa | 10 +-
src/arch/arm/isa/insts/neon.isa | 22 ++
src/arch/arm/isa/insts/neon64.isa | 3 +++
3 files changed, 26 insertions(+), 9 deletions(-)
diffs (113 lines):
diff -r be0e1724eb39 -r a60405212dea src/arch/arm/isa/insts/insts.isa
--- a/src/arch/arm/isa/insts/insts.isa Fri May 09 18:58:47 2014 -0400
+++ b/src/arch/arm/isa/insts/insts.isa Fri May 09 18:58:47 2014 -0400
@@ -53,6 +53,9 @@
##include misc.isa
##include misc64.isa
+split exec;
+split decoder;
+
//Stores of a single item, AArch64
##include str64.isa
@@ -65,6 +68,8 @@
//Load/store multiple
##include macromem.isa
+split exec;
+
//Data processing instructions
##include data.isa
@@ -85,12 +90,15 @@
##include fp.isa
##include fp64.isa
+split exec;
+
//Neon
##include neon.isa
//AArch64 Neon
##include neon64.isa
+split decoder;
##include neon64_mem.isa
-//m5 Psuedo-ops
+//m5 Pseudo-ops
##include m5ops.isa
diff -r be0e1724eb39 -r a60405212dea src/arch/arm/isa/insts/neon.isa
--- a/src/arch/arm/isa/insts/neon.isa Fri May 09 18:58:47 2014 -0400
+++ b/src/arch/arm/isa/insts/neon.isa Fri May 09 18:58:47 2014 -0400
@@ -1058,7 +1058,11 @@
}
}};
-output exec {{
+let {{
+header_output =
+exec_output =
+
+vcompares = '''
static float
vcgtFunc(float op1, float op2)
{
@@ -1082,7 +1086,8 @@
return 2.0;
return (op1 == op2) ? 0.0 : 1.0;
}
-
+'''
+vcomparesL = '''
static float
vcleFunc(float op1, float op2)
{
@@ -1098,7 +1103,8 @@
return 2.0;
return (op1 op2) ? 0.0 : 1.0;
}
-
+'''
+vacomparesG = '''
static float
vacgtFunc(float op1, float op2)
{
@@ -1114,12 +1120,9 @@
return 2.0;
return (fabsf(op1) = fabsf(op2)) ? 0.0 : 1.0;
}
-}};
+'''
-let {{
-
-header_output =
-exec_output =
+exec_output += vcompares + vacomparesG
smallUnsignedTypes = (uint8_t, uint16_t, uint32_t)
unsignedTypes = smallUnsignedTypes + (uint64_t,)
@@ -3414,6 +3417,9 @@
twoRegMiscInst(vrev64, NVrev64D, SimdAluOp, smallUnsignedTypes, 2,
vrev64Code)
twoRegMiscInst(vrev64, NVrev64Q, SimdAluOp, smallUnsignedTypes, 4,
vrev64Code)
+split('exec')
+exec_output += vcompares + vcomparesL
+
vpaddlCode = '''
destElem = (BigElement)srcElem1 + (BigElement)srcElem2;
'''
diff -r be0e1724eb39 -r a60405212dea src/arch/arm/isa/insts/neon64.isa
--- a/src/arch/arm/isa/insts/neon64.isa Fri May 09 18:58:47 2014 -0400
+++ b/src/arch/arm/isa/insts/neon64.isa Fri May 09 18:58:47 2014 -0400
@@ -1959,6 +1959,9 @@
2, minAcrossCode)
twoRegAcrossInstX(sminv, SminvQX, SimdCmpOp, smallSignedTypes, 4,
minAcrossCode)
+
+split('exec')
+
# SMLAL, SMLAL2 (by element)
mlalCode = destElem += (BigElement)srcElem1 * (BigElement)srcElem2;
threeRegLongInstX(smlal, SmlalElemX, SimdMultAccOp,
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in gem5: arch: teach ISA parser how to split code acro...
changeset be0e1724eb39 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=be0e1724eb39
description:
arch: teach ISA parser how to split code across files
This patch encompasses several interrelated and interdependent changes
to the ISA generation step. The end goal is to reduce the size of the
generated compilation units for instruction execution and decoding so
that batch compilation can proceed with all CPUs active without
exhausting physical memory.
The ISA parser (src/arch/isa_parser.py) has been improved so that it can
accept 'split [output_type];' directives at the top level of the grammar
and 'split(output_type)' python calls within 'exec {{ ... }}' blocks.
This has the effect of splitting the files into smaller compilation
units. I use air-quotes around splitting because the files themselves
are not split, but preprocessing directives are inserted to have the
same
effect.
Architecturally, the ISA parser has had some changes in how it works.
In general, it emits code sooner. It doesn't generate per-CPU files,
and instead defers to the C preprocessor to create the duplicate copies
for each CPU type. Likewise there are more files emitted and the C
preprocessor does more substitution that used to be done by the ISA
parser.
Finally, the build system (SCons) needs to be able to cope with a
dynamic list of source files coming out of the ISA parser. The changes
to the SCons{cript,truct} files support this. In broad strokes, the
targets requested on the command line are hidden from SCons until all
the build dependencies are determined, otherwise it would try, realize
it can't reach the goal, and terminate in failure. Since build steps
(i.e. running the ISA parser) must be taken to determine the file list,
several new build stages have been inserted at the very start of the
build. First, the build dependencies from the ISA parser will be emitted
to arch/$ISA/generated/inc.d, which is then read by a new SCons builder
to finalize the dependencies. (Once inc.d exists, the ISA parser will
not
need to be run to complete this step.) Once the dependencies are known,
the 'Environments' are made by the makeEnv() function. This function
used
to be called before the build began but now happens during the build.
It is easy to see that this step is quite slow; this is a known issue
and it's important to realize that it was already slow, but there was
no obvious cause to attribute it to since nothing was displayed to the
terminal. Since new steps that used to be performed serially are now in
a
potentially-parallel build phase, the pathname handling in the SCons
scripts
has been tightened up to deal with chdir() race conditions. In general,
pathnames are computed earlier and more likely to be stored, passed
around,
and processed as absolute paths rather than relative paths. In the end,
some of these issues had to be fixed by inserting serializing
dependencies
in the build.
Minor note:
For the null ISA, we just provide a dummy inc.d so SCons is never
compelled to try to generate it. While it seems slightly wrong to have
anything in src/arch/*/generated (i.e. a non-generated 'generated'
file),
it's by far the simplest solution.
diffstat:
SConstruct | 66 +++-
src/SConscript | 132 +--
src/arch/SConscript | 76 -
src/arch/alpha/SConscript|7 +-
src/arch/alpha/isa/fp.isa|6 +-
src/arch/alpha/isa/main.isa |4 +-
src/arch/alpha/isa/mem.isa | 24 +-
src/arch/alpha/isa/opcdec.isa|2 +-
src/arch/alpha/isa/unimp.isa |4 +-
src/arch/alpha/isa/unknown.isa |2 +-
src/arch/arm/SConscript |9 +-
src/arch/arm/isa/formats/breakpoint.isa |2 +-
src/arch/arm/isa/formats/unimp.isa |6 +-
src/arch/arm/isa/templates/basic.isa |2 +-
src/arch/arm/isa/templates/macromem.isa | 10 +-
src/arch/arm/isa/templates/mem.isa | 42 +-
src/arch/arm/isa/templates/mem64.isa | 22 +-
src/arch/arm/isa/templates/neon.isa |6 +-
src/arch/arm/isa/templates/neon64.isa| 20 +-
src/arch/arm/isa/templates/pred.isa |6 +-
src/arch/isa_parser.py | 489 +-
src/arch/mips/SConscript |7 +-
src/arch/mips/isa/formats/basic.isa |2 +-
src/arch/mips/isa/formats/control.isa| 12 +-
src/arch/mips/isa/formats/dsp.isa|8 +-
src/arch/mips/isa/formats/fp.isa | 10 +-
[gem5-dev] changeset in gem5: cpu: add more instruction mix statistics
changeset d717abc806aa in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=d717abc806aa
description:
cpu: add more instruction mix statistics
For the o3, add instruction mix (OpClass) histogram at commit (stats
also already collected at issue). For the simple CPUs we add a
histogram of executed instructions
diffstat:
src/cpu/o3/commit.hh | 2 ++
src/cpu/o3/commit_impl.hh | 9 +
src/cpu/simple/base.cc| 12
src/cpu/simple/base.hh| 3 +++
4 files changed, 26 insertions(+), 0 deletions(-)
diffs (80 lines):
diff -r 5c2c4195b839 -r d717abc806aa src/cpu/o3/commit.hh
--- a/src/cpu/o3/commit.hh Fri May 09 18:58:46 2014 -0400
+++ b/src/cpu/o3/commit.hh Fri May 09 18:58:47 2014 -0400
@@ -532,6 +532,8 @@
Stats::Vector statComInteger;
/** Total number of function calls */
Stats::Vector statComFunctionCalls;
+/** Committed instructions by instruction type (OpClass) */
+Stats::Vector2d statCommittedInstType;
/** Number of cycles where the commit bandwidth limit is reached. */
Stats::Scalar commitEligibleSamples;
diff -r 5c2c4195b839 -r d717abc806aa src/cpu/o3/commit_impl.hh
--- a/src/cpu/o3/commit_impl.hh Fri May 09 18:58:46 2014 -0400
+++ b/src/cpu/o3/commit_impl.hh Fri May 09 18:58:47 2014 -0400
@@ -273,6 +273,14 @@
.flags(total)
;
+statCommittedInstType
+.init(numThreads,Enums::Num_OpClass)
+.name(name() + .op_class)
+.desc(Class of committed instruction)
+.flags(total | pdf | dist)
+;
+statCommittedInstType.ysubnames(Enums::OpClassStrings);
+
commitEligible
.init(cpu-numThreads)
.name(name() + .bw_limited)
@@ -1032,6 +1040,7 @@
if (commit_success) {
++num_committed;
+statCommittedInstType[tid][head_inst-opClass()]++;
ppCommit-notify(head_inst);
changedROBNumEntries[tid] = true;
diff -r 5c2c4195b839 -r d717abc806aa src/cpu/simple/base.cc
--- a/src/cpu/simple/base.ccFri May 09 18:58:46 2014 -0400
+++ b/src/cpu/simple/base.ccFri May 09 18:58:47 2014 -0400
@@ -286,6 +286,16 @@
.prereq(dcacheRetryCycles)
;
+statExecutedInstType
+.init(Enums::Num_OpClass)
+.name(name() + .op_class)
+.desc(Class of executed instruction)
+.flags(total | pdf | dist)
+;
+for (unsigned i = 0; i Num_OpClasses; ++i) {
+statExecutedInstType.subname(i, Enums::OpClassStrings[i]);
+}
+
idleFraction = constant(1.0) - notIdleFraction;
numIdleCycles = idleFraction * numCycles;
numBusyCycles = (notIdleFraction)*numCycles;
@@ -532,6 +542,8 @@
}
/* End power model statistics */
+statExecutedInstType[curStaticInst-opClass()]++;
+
if (FullSystem)
traceFunctions(instAddr);
diff -r 5c2c4195b839 -r d717abc806aa src/cpu/simple/base.hh
--- a/src/cpu/simple/base.hhFri May 09 18:58:46 2014 -0400
+++ b/src/cpu/simple/base.hhFri May 09 18:58:47 2014 -0400
@@ -283,6 +283,9 @@
Stats::Scalar numBranchMispred;
/// @}
+// instruction mix histogram by OpClass
+Stats::Vector statExecutedInstType;
+
void serializeThread(std::ostream os, ThreadID tid);
void unserializeThread(Checkpoint *cp, const std::string section,
ThreadID tid);
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2247: arch: teach ISA parser how to split code across files
On May 5, 2014, 6:06 a.m., Steve Reinhardt wrote: src/arch/isa_parser.py, line 2233 http://reviews.gem5.org/r/2247/diff/1/?file=39628#file39628line2233 I can see that this is more localized, but what about just going into the templates and replacing '%(CPU_exec_context)s' with CPU_EXEC_CONTEXT (perl -pi -e could do this in a flash)... then we wouldn't need this function at all. Particularly if you're worried about runtime, it seems odd to to this same static substitution dynamically every time we run the parser vs. just doing it once for all time offline. I agree with this and will update the patch. - Curtis --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2247/#review5083 --- On April 23, 2014, 12:23 p.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2247/ --- (Updated April 23, 2014, 12:23 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10199:5f265b5de1c5 --- arch: teach ISA parser how to split code across files This patch is the first step in enabling the ISA-parser to split the output into multiple files and thereby reach a more sensible compilation-unit size. Diffs - src/arch/isa_parser.py e40b35147270 Diff: http://reviews.gem5.org/r/2247/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Review Request 2248: arch: support dynamic ISA file generation in SConscripts
--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2248/#review5088 --- src/SConscript http://reviews.gem5.org/r/2248/#comment4618 I suppose this change could be applied independent of the ISA splitting work, but it wouldn't fix anything in that case. (It'd be pointless/change for change's sake) With dynamic source files as a result of ISA splitting, makeEnv() gets called during the build instead of before it. This makes dealing with pathnames more challenging since chdir()'s are happening asynchronously in parallel with what makeEnv() might be doing. This little bit of code helps to work around that issue. tests/SConscript http://reviews.gem5.org/r/2248/#comment4619 Like the other bit of code you commented on, this makes the code deal with absolute paths rather than relative paths. It's not necessary in isolation. It was my intention for all of this to be all required for ISA splitting; these changes just address one aspect of the solution. If one single changeset is desired, this should be folded into the other ISA splitting changes. - Curtis Dunham On April 23, 2014, 12:23 p.m., Andreas Hansson wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2248/ --- (Updated April 23, 2014, 12:23 p.m.) Review request for Default. Repository: gem5 Description --- Changeset 10200:0e0cf51add93 --- arch: support dynamic ISA file generation in SConscripts Diffs - SConstruct e40b35147270 src/SConscript e40b35147270 src/arch/SConscript e40b35147270 tests/SConscript e40b35147270 Diff: http://reviews.gem5.org/r/2248/diff/ Testing --- Thanks, Andreas Hansson ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
