date:20110318

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

2011-03-18 Thread Nilay Vaish


On Fri, 18 Mar 2011, Lisa Hsu wrote:


What's going on with this patch?  I don't believe it's been committed but it
seems like it should.  I've also got some patches waiting behind this
because they used to touch CacheMsg and I don't want to mess Nilay up, so
I've been waiting to serialize behind this.

Lisa



Lisa, the original patch was pretty long and after some of the changes 
that Brad submitted, almost the whole of the patch required rework. I have 
already committed some parts of the original patch. I have posted two more 
patches on the review board that cover some more portion of the patch. You 
can ignore the original patch. Assume that I will not post more patches 
that touch CacheMsg or related structures apart from the two that I posted 
5 minutes ago.


--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Ruby: Convert CacheRequestType to RubyRequestType

2011-03-18 Thread Nilay Vaish


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/602/
---

Review request for Default.


Summary
---

Ruby: Convert CacheRequestType to RubyRequestType
This patch converts CacheRequestType to RubyRequestType so that both the
protocol dependent and independent code makes use of the same request type.


Diffs
-

  src/mem/protocol/MESI_CMP_directory-L1cache.sm 9a6a02a235f1 
  src/mem/protocol/MI_example-cache.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_CMP_directory-L1cache.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_hammer-cache.sm 9a6a02a235f1 
  src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1 
  src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1 
  src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1 
  src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1 
  src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1 
  src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1 
  src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1 
  src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1 
  src/mem/ruby/profiler/Profiler.cc 9a6a02a235f1 
  src/mem/ruby/recorder/CacheRecorder.hh 9a6a02a235f1 
  src/mem/ruby/recorder/Tracer.hh 9a6a02a235f1 
  src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1 
  src/mem/ruby/slicc_interface/RubyRequest.cc 9a6a02a235f1 
  src/mem/ruby/slicc_interface/RubySlicc_Util.hh 9a6a02a235f1 
  src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1 
  src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1 
  src/mem/ruby/system/DMASequencer.cc 9a6a02a235f1 
  src/mem/ruby/system/Sequencer.hh 9a6a02a235f1 
  src/mem/ruby/system/Sequencer.cc 9a6a02a235f1 

Diff: http://reviews.m5sim.org/r/602/diff


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: Ruby: Convert AccessModeType to RubyAccessMode

2011-03-18 Thread Nilay Vaish


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/601/
---

Review request for Default.


Summary
---

Ruby: Convert AccessModeType to RubyAccessMode
This patch converts AccessModeType to RubyAccessMode so that both the
protocol dependent and independent code uses the same access mode.


Diffs
-

  src/cpu/testers/rubytest/Check.hh 9a6a02a235f1 
  src/cpu/testers/rubytest/Check.cc 9a6a02a235f1 
  src/mem/protocol/MESI_CMP_directory-msg.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_CMP_directory-msg.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_CMP_token-L1cache.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_CMP_token-dir.sm 9a6a02a235f1 
  src/mem/protocol/MOESI_CMP_token-msg.sm 9a6a02a235f1 
  src/mem/protocol/RubySlicc_Exports.sm 9a6a02a235f1 
  src/mem/protocol/RubySlicc_Types.sm 9a6a02a235f1 
  src/mem/ruby/profiler/AccessTraceForAddress.hh 9a6a02a235f1 
  src/mem/ruby/profiler/AccessTraceForAddress.cc 9a6a02a235f1 
  src/mem/ruby/profiler/AddressProfiler.hh 9a6a02a235f1 
  src/mem/ruby/profiler/AddressProfiler.cc 9a6a02a235f1 
  src/mem/ruby/profiler/CacheProfiler.hh 9a6a02a235f1 
  src/mem/ruby/profiler/CacheProfiler.cc 9a6a02a235f1 
  src/mem/ruby/profiler/Profiler.hh 9a6a02a235f1 
  src/mem/ruby/slicc_interface/RubyRequest.hh 9a6a02a235f1 
  src/mem/ruby/system/CacheMemory.hh 9a6a02a235f1 
  src/mem/ruby/system/CacheMemory.cc 9a6a02a235f1 
  src/mem/ruby/system/Sequencer.hh 9a6a02a235f1 
  src/mem/ruby/system/Sequencer.cc 9a6a02a235f1 

Diff: http://reviews.m5sim.org/r/601/diff


Testing
---


Thanks,

Nilay

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst

2011-03-18 Thread Ali Saidi



> On 2011-03-03 20:41:09, Ali Saidi wrote:
> > Please don't ship this until I have a chance to try it, I just want to make 
> > sure it doesn't break ARM_FS/O3.
> 
> Korey Sewell wrote:
> Sure, I'd welcome a go of things from some other folks to test if I 
> haven't introduced something quirky.
> 
> After there is some commentary, I'll make sure to run the full 
> regressions before committing this because as we all know BaseDynInst is a 
> pretty fundamental part of M5.
> 
> Also, I'll be posting an update to this diff soon that will make the 
> setRegOperand pure virtual (I mistakenly thought those were 
> templated member functions in the first go-round).
> 
> Ali Saidi wrote:
> Anything happen with your update diff? If you could verify it passes the 
> arm/o3 full system regression I just committed and then I'll give it a go on 
> a bunch more tests.
> 
> Korey Sewell wrote:
> Gabe made a good point about the virtual function overhead on the 
> commonly used set*Operand functions and I've just been waffling on whether to 
> even make those pure virtual or not.
> 
> However, I'll go ahead and take a hard look at this again , run the 
> regressions, and post an update tomorrow so we can move on with this 
> potential change.
> 
> Korey Sewell wrote:
> The ARM regressions pass with this patch. Feel free to do further testing.

What about the virtual function overhead?


- Ali


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/529/#review932
---


On 2011-03-01 13:49:24, Korey Sewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/529/
> ---
> 
> (Updated 2011-03-01 13:49:24)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> cpu: split o3-specific parts out of BaseDynInst
> The bigger picture goal is that I want to get the InorderDynInst class 
> derived from the
> BaseDynInst, since there is no need to replicate a lot of useful code already 
> defined
> in BaseDynInst (e.g. microcode identification, etc.) and Inorder can take 
> advantage
> of common code that handles microcode and other features that other ISAs need.
> 
> But to do this, there are a lot of o3-specific things that are in 
> BaseDynInst, that I pushed to
> O3DynInst in this patch. Book-keeping variables that handle the IQ,LSQ,ROB 
> are unnecessary in
> the base class but generic variables that will work across CPUs (IsSquashed, 
> IsCompleted, etc.)
> are kept in the base class.
> 
> The upside is more consistency across the simple models (branch prediction 
> and instruction
> identification are all in one common place).
> 
> I really wanted to define pure virtual functions for read/write(to memory) 
> and the
> setRegOperand, but virtual functions in a templated class is a 
> no-no and
> I couldn't get around that (suggestions?).
> 
> Also, I'd rather not use the "this->" pointer all over the place to access 
> member variables of
> the templated Base class, but it had to be done.
> 
> Other than those quirks, simulator functionality should stay the same as the 
> O3 Model always references
> the O3DynInst pointer and the InOrder model doesnt currently make use of the 
> base dyn inst. class.
> (but it will be easier to derive from now...)
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh cf1afc88070f 
>   src/cpu/base_dyn_inst_impl.hh cf1afc88070f 
>   src/cpu/o3/dyn_inst.hh cf1afc88070f 
>   src/cpu/o3/dyn_inst_impl.hh cf1afc88070f 
> 
> Diff: http://reviews.m5sim.org/r/529/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Korey
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: se.py: Modify script to make multiprogramming much easier.

2011-03-18 Thread Gabe Black


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/598/#review993
---



configs/example/se.py


Splitting on "," would be a little more standard.


- Gabe


On 2011-03-18 16:06:02, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/598/
> ---
> 
> (Updated 2011-03-18 16:06:02)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> se.py: Modify script to make multiprogramming much easier.
> Now, instead of --bench benchname, you can do --bench bench1-bench2-bench3 
> and it will
> set up a simulation that instantiates those three workloads.  Only caveat is 
> that now,
> for sanity checking, your -n X must match the number of benches in the list.
> 
> 
> Diffs
> -
> 
>   configs/example/se.py b0ecadb07742 
> 
> Diff: http://reviews.m5sim.org/r/598/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: configs: combine ruby_se.py and se.py to avoid all that code duplication

2011-03-18 Thread Gabe Black

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/600/#review992
---

configs/example/se.py

I applaud getting rid of the duplication, but isn't it a little dangerous 
here to set up a fake TimingSimpleCPU class and to ignore the se.py options? 
Maybe you should have a warning if the options don't match what you're forcing? 
That would avoid any potential confusion.

Alternatively it might make sense to factor out the common parts of this 
script into a bunch of stuff that other people can use in an se.py like script 
of their own. That would be nice in the long term, but getting rid of all that 
code is still great right now.

- Gabe

On 2011-03-18 16:06:49, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/600/
> ---
> 
> (Updated 2011-03-18 16:06:49)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> configs: combine ruby_se.py and se.py to avoid all that code duplication
> 
> 
> Diffs
> -
> 
>   configs/example/ruby_se.py b0ecadb07742 
>   configs/example/se.py b0ecadb07742 
> 
> Diff: http://reviews.m5sim.org/r/600/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: enable x86 workloads on se.py

2011-03-18 Thread Ali Saidi


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/599/#review991
---



configs/example/se.py


Why not just change this to exec("workload = %s(buildEnv['TARGET_ISA'], 
'linux', 'ref')" % app) ? I realize that alpha is a special case with tru64, 
but everything else is linux.



- Ali


On 2011-03-18 16:06:35, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/599/
> ---
> 
> (Updated 2011-03-18 16:06:35)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> enable x86 workloads on se.py
> 
> 
> Diffs
> -
> 
>   configs/example/se.py b0ecadb07742 
> 
> Diff: http://reviews.m5sim.org/r/599/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst

2011-03-18 Thread Korey Sewell



> On 2011-03-03 20:41:09, Ali Saidi wrote:
> > Please don't ship this until I have a chance to try it, I just want to make 
> > sure it doesn't break ARM_FS/O3.
> 
> Korey Sewell wrote:
> Sure, I'd welcome a go of things from some other folks to test if I 
> haven't introduced something quirky.
> 
> After there is some commentary, I'll make sure to run the full 
> regressions before committing this because as we all know BaseDynInst is a 
> pretty fundamental part of M5.
> 
> Also, I'll be posting an update to this diff soon that will make the 
> setRegOperand pure virtual (I mistakenly thought those were 
> templated member functions in the first go-round).
> 
> Ali Saidi wrote:
> Anything happen with your update diff? If you could verify it passes the 
> arm/o3 full system regression I just committed and then I'll give it a go on 
> a bunch more tests.
> 
> Korey Sewell wrote:
> Gabe made a good point about the virtual function overhead on the 
> commonly used set*Operand functions and I've just been waffling on whether to 
> even make those pure virtual or not.
> 
> However, I'll go ahead and take a hard look at this again , run the 
> regressions, and post an update tomorrow so we can move on with this 
> potential change.

The ARM regressions pass with this patch. Feel free to do further testing.


- Korey


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/529/#review932
---


On 2011-03-01 13:49:24, Korey Sewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/529/
> ---
> 
> (Updated 2011-03-01 13:49:24)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> cpu: split o3-specific parts out of BaseDynInst
> The bigger picture goal is that I want to get the InorderDynInst class 
> derived from the
> BaseDynInst, since there is no need to replicate a lot of useful code already 
> defined
> in BaseDynInst (e.g. microcode identification, etc.) and Inorder can take 
> advantage
> of common code that handles microcode and other features that other ISAs need.
> 
> But to do this, there are a lot of o3-specific things that are in 
> BaseDynInst, that I pushed to
> O3DynInst in this patch. Book-keeping variables that handle the IQ,LSQ,ROB 
> are unnecessary in
> the base class but generic variables that will work across CPUs (IsSquashed, 
> IsCompleted, etc.)
> are kept in the base class.
> 
> The upside is more consistency across the simple models (branch prediction 
> and instruction
> identification are all in one common place).
> 
> I really wanted to define pure virtual functions for read/write(to memory) 
> and the
> setRegOperand, but virtual functions in a templated class is a 
> no-no and
> I couldn't get around that (suggestions?).
> 
> Also, I'd rather not use the "this->" pointer all over the place to access 
> member variables of
> the templated Base class, but it had to be done.
> 
> Other than those quirks, simulator functionality should stay the same as the 
> O3 Model always references
> the O3DynInst pointer and the InOrder model doesnt currently make use of the 
> base dyn inst. class.
> (but it will be easier to derive from now...)
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh cf1afc88070f 
>   src/cpu/base_dyn_inst_impl.hh cf1afc88070f 
>   src/cpu/o3/dyn_inst.hh cf1afc88070f 
>   src/cpu/o3/dyn_inst_impl.hh cf1afc88070f 
> 
> Diff: http://reviews.m5sim.org/r/529/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Korey
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

2011-03-18 Thread Lisa Hsu

What's going on with this patch?  I don't believe it's been committed but it
seems like it should.  I've also got some patches waiting behind this
because they used to touch CacheMsg and I don't want to mess Nilay up, so
I've been waiting to serialize behind this.

Lisa

On Wed, Feb 9, 2011 at 1:28 PM, Brad Beckmann  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/327/
>
> Overall, this patch looks good to me as well.  I just have a couple minor 
> questions.  Though your comment says this patch removes libruby, the diff 
> seems to indicate that the file still remains.  Am I reading that correctly?  
> Also it seems that in several places you unecessarily generate the line 
> address, even though the line address already exists in the ruby request (see 
> comments below).
>
>
>
> src/mem/ruby/storebuffer/storebuffer.cc
>  (Diff
> revision 6)
>
> StoreBuffer::checkForLoadHit(RubyRequest request)
>
>   183
>
> if ((req.paddr & m_block_mask) != lineaddr)
>
> 183
>
> if ((req.m_PhysicalAddress.getAddress() & m_block_mask) != lineaddr)
>
>   Instead of masking the physical address, can we just use the m_LineAddress?
>
>
>
> src/mem/ruby/storebuffer/storebuffer.cc
>  (Diff
> revision 6)
>
> StoreBuffer::returnMatchedData(RubyRequest request)
>
>   233
>
> if ((it->m_request.paddr & m_block_mask) == lineaddr) {
>
> 233
>
> if ((it->m_request.m_PhysicalAddress.getAddress() & m_block_mask) == 
> lineaddr) {
>
>   Same here.  Can we just use the m_LineAddress?
>
>
>
> src/mem/ruby/storebuffer/storebuffer.cc
>  (Diff
> revision 6)
>
> StoreBuffer::complete(uint64_t id)
>
>   308
>
> if ((from_buffer.m_request.paddr & m_block_mask) == lineaddr &&
>
> 308
>
> if ((from_buffer.m_request.m_PhysicalAddress.getAddress() & 
> m_block_mask) == lineaddr &&
>
>   And here
>
>
>
> src/mem/ruby/system/Sequencer.cc
>  (Diff
> revision 6)
>
> Sequencer::insertRequest(SequencerRequest* request)
>
>   230
>
> line_addr.makeLineAddress();
>
> 231
>
> Address line_addr(ruby_request->m_LineAddress);
>
>   Why is this line address conversion necessary?  Isn't m_LineAddress already 
> set correctly in the constructor?
>
>
>
> src/mem/ruby/system/Sequencer.cc
>  (Diff
> revision 6)
>
> Sequencer::hitCallback(SequencerRequest* srequest,
>
>   451
>
> Address request_line_address(ruby_request.paddr);
>
> 453
>
> Address request_line_address(ruby_request->m_PhysicalAddress);
>
>   Can you just use the m_LineAddress variable of ruby_request instead of 
> converting the paddr to a line address.
>
>
> - Brad
>
> On January 25th, 2011, 9:15 a.m., Nilay Vaish wrote:
>   Review request for Default.
> By Nilay Vaish.
>
> *Updated 2011-01-25 09:15:23*
> Description
>
> Remove CacheMsg class from SLICC
> The goal of the patch is to do away with the CacheMsg class currently in use
> in coherence protocols. In place of CacheMsg, the RubyRequest class will used.
> This class is already present in libruby.hh. In fact, objects of class
> CacheMsg are generated by copying values from a RubyRequest object.
>
> The changes relating to removal of libruby have been moved to separate patch.
>
>   Diffs
>
>- src/cpu/testers/rubytest/RubyTester.hh (31a04e5ac4be)
>- src/mem/protocol/MESI_CMP_directory-L1cache.sm (31a04e5ac4be)
>- src/mem/protocol/MI_example-cache.sm (31a04e5ac4be)
>- src/mem/protocol/MOESI_CMP_directory-L1cache.sm (31a04e5ac4be)
>- src/mem/protocol/MOESI_CMP_token-L1cache.sm (31a04e5ac4be)
>- src/mem/protocol/MOESI_CMP_token-dir.sm (31a04e5ac4be)
>- src/mem/protocol/MOESI_hammer-cache.sm (31a04e5ac4be)
>- src/mem/protocol/RubySlicc_Exports.sm (31a04e5ac4be)
>- src/mem/protocol/RubySlicc_Profiler.sm (31a04e5ac4be)
>- src/mem/protocol/RubySlicc_Types.sm (31a04e5ac4be)
>- src/mem/ruby/SConscript (31a04e5ac4be)
>- src/mem/ruby/common/Address.hh (31a04e5ac4be)
>- src/mem/ruby/common/Address.cc (31a04e5ac4be)
>- src/mem/ruby/common/DataBlock.hh (31a04e5ac4be)
>- src/mem/ruby/common/DataBlock.cc (31a04e5ac4be)
>- src/mem/ruby/filters/BlockBloomFilter.cc (31a04e5ac4be)
>- src/mem/ruby/filters/BulkBloomFilter.cc (31a04e5ac4be)
>- src/mem/ruby/filters/LSB_CountingBloomFilter.cc (31a04e5ac4be)
>- src/mem/ruby/filters/MultiGrainBloomFilter.cc (31a04e5ac4be)
>- src/mem/ruby/filters/NonCountingBloomFilter.cc (31a04e5ac4be)
>- src/mem/ruby/libruby.hh (31a04e5ac4be)
>- src/mem/ruby/libruby.cc (31a04e5ac4be)
>- src/mem/ruby/libruby_internal.hh (31a04e5ac4be)
>- src/mem/ruby/profiler/AccessTraceForAdd

[m5-dev] Review Request: configs: combine ruby_se.py and se.py to avoid all that code duplication

2011-03-18 Thread Lisa Hsu


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/600/
---

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

configs: combine ruby_se.py and se.py to avoid all that code duplication


Diffs
-

  configs/example/ruby_se.py b0ecadb07742 
  configs/example/se.py b0ecadb07742 

Diff: http://reviews.m5sim.org/r/600/diff


Testing
---


Thanks,

Lisa

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: enable x86 workloads on se.py

2011-03-18 Thread Lisa Hsu


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/599/
---

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

enable x86 workloads on se.py


Diffs
-

  configs/example/se.py b0ecadb07742 

Diff: http://reviews.m5sim.org/r/599/diff


Testing
---


Thanks,

Lisa

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Review Request: se.py: Modify script to make multiprogramming much easier.

2011-03-18 Thread Lisa Hsu


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/598/
---

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

se.py: Modify script to make multiprogramming much easier.
Now, instead of --bench benchname, you can do --bench bench1-bench2-bench3 and 
it will
set up a simulation that instantiates those three workloads.  Only caveat is 
that now,
for sanity checking, your -n X must match the number of benches in the list.


Diffs
-

  configs/example/se.py b0ecadb07742 

Diff: http://reviews.m5sim.org/r/598/diff


Testing
---


Thanks,

Lisa

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

2011-03-18 Thread Steve Reinhardt



> On 2011-03-18 13:57:35, Gabe Black wrote:
> > src/sim/syscall_emul.hh, line 503
> > 
> >
> > Why is this change necessary? I'm not 100% sure why it was the way it 
> > was before, but I see no reason to change it either. Changing the fatal to 
> > a warn may be necessary to get some benchmark to run, but I'm talking 
> > specifically about the ones that would return -ENOTTY.
> 
> Vince Weaver wrote:
> It's been a while, but let's see if I can see what's going on.
> 
> Before we had a short list of ioctls we return -ENOTTY for, any not on 
> the list gave a fatal error.
> 
> ENOTTY if I recall correctly is the typical way the kernel reports an 
> ioctl not being implemented.  So by changing all ioctls to warn and then 
> report ENOTTY we are saying that we don't support it, but the program can 
> keep running assuming it handles an ENOTTY properly.
> 
> For most of the SPEC benchmarks ioctl() calls aren't important for 
> correctness, so this works.  
> 
> We could go back to having a whitelist of known-to-be-OK-to-ignore 
> ioctls(), but it might turn out to be a lengthy list, and also we probably 
> should implement things like isatty() properly as I do think some benchmarks 
> depend on it returning the right value
> (see http://www.cs.binghamton.edu/~msim/wiki/index.php/TIOCISATTY )
>
> 
> Gabe Black wrote:
> isatty is actually pretty annoying, and it's important that it -not- 
> always return the right answer. It needs to be consistent regardless of 
> whether your piping output to a file or watching it on the console so runs 
> are deterministic, and if it always thinks it's going to a tty it'll buffer 
> properly for when it's actually going to a tty (and doesn't look like 
> something's broken, basically) and just perform a little worse when it's not. 
> As far as simulator performance it doesn't matter since I'm sure it's a long 
> way from being the critical path, and it should be a reasonable situation as 
> far as simulated performance.
> 
> I think a whitelist is a good idea, and we don't have to have -all- the 
> ok to ignore ones on there, just the ok to ignore ones that actually get 
> called. That should be a lot more manageable list. That way you know if 
> something out of the ordinary is happening (the simulator will bomb out) 
> rather than something weird happening and the benchmark stumbling on to 
> eventually die, potentially far from evidence of what happened. The later is 
> a lot harder to debug.

ENOTTY is just the way the kernel reports a TTY-specific ioctl being invoked on 
a non-TTY device.  Gabe is right that for repeatability you always want the 
simulator to always act like there's no tty for determinism.  I would prefer to 
see us figure out what other ioctls need to be added to the TTY-specific list 
than to make a blanket assumption that any ioctl that's called is TTY-specific.


- Steve


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/589/#review981
---


On 2011-03-17 16:06:13, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/589/
> ---
> 
> (Updated 2011-03-17 16:06:13)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86 ioctl:  Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
>   src/sim/syscall_emul.hh 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/589/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

2011-03-18 Thread Gabe Black

> On 2011-03-18 13:57:35, Gabe Black wrote:
> > src/sim/syscall_emul.hh, line 503
> > 
> >
> > Why is this change necessary? I'm not 100% sure why it was the way it 
> > was before, but I see no reason to change it either. Changing the fatal to 
> > a warn may be necessary to get some benchmark to run, but I'm talking 
> > specifically about the ones that would return -ENOTTY.
> 
> Vince Weaver wrote:
> It's been a while, but let's see if I can see what's going on.
> 
> Before we had a short list of ioctls we return -ENOTTY for, any not on 
> the list gave a fatal error.
> 
> ENOTTY if I recall correctly is the typical way the kernel reports an 
> ioctl not being implemented.  So by changing all ioctls to warn and then 
> report ENOTTY we are saying that we don't support it, but the program can 
> keep running assuming it handles an ENOTTY properly.
> 
> For most of the SPEC benchmarks ioctl() calls aren't important for 
> correctness, so this works.  
> 
> We could go back to having a whitelist of known-to-be-OK-to-ignore 
> ioctls(), but it might turn out to be a lengthy list, and also we probably 
> should implement things like isatty() properly as I do think some benchmarks 
> depend on it returning the right value
> (see http://www.cs.binghamton.edu/~msim/wiki/index.php/TIOCISATTY )
>

isatty is actually pretty annoying, and it's important that it -not- always 
return the right answer. It needs to be consistent regardless of whether your 
piping output to a file or watching it on the console so runs are 
deterministic, and if it always thinks it's going to a tty it'll buffer 
properly for when it's actually going to a tty (and doesn't look like 
something's broken, basically) and just perform a little worse when it's not. 
As far as simulator performance it doesn't matter since I'm sure it's a long 
way from being the critical path, and it should be a reasonable situation as 
far as simulated performance.

I think a whitelist is a good idea, and we don't have to have -all- the ok to 
ignore ones on there, just the ok to ignore ones that actually get called. That 
should be a lot more manageable list. That way you know if something out of the 
ordinary is happening (the simulator will bomb out) rather than something weird 
happening and the benchmark stumbling on to eventually die, potentially far 
from evidence of what happened. The later is a lot harder to debug.

- Gabe

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/589/#review981
---

On 2011-03-17 16:06:13, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/589/
> ---
> 
> (Updated 2011-03-17 16:06:13)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86 ioctl:  Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
>   src/sim/syscall_emul.hh 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/589/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-18 Thread Gabe Black



> On 2011-02-27 21:41:48, Gabe Black wrote:
> > Should we put an assert in there to make sure no access is bigger than 16 
> > bytes? Also what about unaligned accesses? I think those will be split on 
> > cache block boundaries which may be bigger or smaller than 16 bytes. We 
> > might have an access that spans from one 16 byte chunk to the next. These 
> > aren't really problems with this change, but it might make them easier to 
> > hit.
> > 
> > I'm assuming this had some effect on the regressions. Did things generally 
> > go faster, slower, etc.?
> 
> Ali Saidi wrote:
> Not major changes, but things usually sped up a little bit.
> 
> Ali Saidi wrote:
> Actually it is quite a change for some benchmarks, it's just not uniform. 
> High of 17%, low of 0%, average of about 5%. So I think we need to fix it and 
> if it exposes other bugs, so be it, but the regression tests all complete 
> successfully. 
> 
> alpha
> --
> eon: 17%
> twolf: 15%
> vortex: 5%
> gzip 0%
> linux: 0%
> bzip2: 3%
> perlbmk: 2%
> 
> 
> parc
> 
> gzip: 3%
> 
> x86
> 
> mcf: 17%
> parser: 4%
> twolf: 2%
> gzip: 2%
> 
> arm
> --
> gzip: 7%
> mcf: 2%
> eon: 13%
> twolf: 3%
> parser: 3%
> vortex: 6%
> perlbmk: 
> bzip2:
> linux: 1%
> 
>

Yes, we shouldn't delay fixing this bug for the sake of the other ones that 
might be in there too. We should still add an assert if possible, though, so we 
catch those bugs if they happen.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review915
---


On 2011-02-27 18:52:51, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-02-27 18:52:51)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: sparc: compilation fixes for inorder

2011-03-18 Thread Gabe Black



> On 2011-03-16 15:17:00, Gabe Black wrote:
> > src/arch/sparc/registers.hh, line 80
> > 
> >
> > This seems redundant. Can't the CPU model add them up just as easily?
> 
> Korey Sewell wrote:
> The CPU Model could calculate these but it would be the same line 
> wherever you put it. 
> 
> I'm not sure it's redundant though, since there isn't necessarily a 
> constant that just encapsulates all the registers available and there other 
> places throughout the code where we are adding constants together to make a 
> easy generic term to use for other objects to draw form.
> 
> Overall, I thought this was the right place because all the register 
> dependency tracking and sizing of Register Files basically uses this file's 
> constants.

Ok. It's not a huge deal where exactly it ends up, although it would be nice to 
put it in a common place since it'll (most likely) be the same everywhere. 
Maybe in cpu/base.hh or something like that. That's not necessarily the perfect 
place since it's not really a constant that belongs to the CPU. It's ok to 
leave it here at least for now.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/583/#review967
---


On 2011-03-14 17:39:33, Korey Sewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/583/
> ---
> 
> (Updated 2011-03-14 17:39:33)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> sparc: compilation fixes for inorder
> Add a few constants and functions that the InOrder model wants for SPARC.
> * * *
> sparc: add eaComp function
> InOrder separates the address generation from the actual access so give
> Sparc that functionality
> * * *
> sparc: add control flags for branches
> branch predictors and other cpu model functions need to know specific 
> information
> about branches, so add the necessary flags here
> 
> 
> Diffs
> -
> 
>   src/arch/sparc/isa/decoder.isa 6c9b532da0a6 
>   src/arch/sparc/isa/formats/branch.isa 6c9b532da0a6 
>   src/arch/sparc/isa/formats/mem/basicmem.isa 6c9b532da0a6 
>   src/arch/sparc/isa/formats/mem/swap.isa 6c9b532da0a6 
>   src/arch/sparc/isa/formats/mem/util.isa 6c9b532da0a6 
>   src/arch/sparc/mt.hh PRE-CREATION 
>   src/arch/sparc/registers.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.cc 6c9b532da0a6 
>   src/cpu/inorder/inorder_dyn_inst.cc 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/583/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Korey
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: isa: get rid of expandForMT function

2011-03-18 Thread Gabe Black


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/578/#review982
---

Ship it!


Looks good. Thanks for fixing it up.

- Gabe


On 2011-03-17 20:17:57, Korey Sewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/578/
> ---
> 
> (Updated 2011-03-17 20:17:57)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> isa: get rid of expandForMT function
> MIPS is the only ISA that cares about having a piece of ISA state integrate
> multiple threads so add constants for MIPS and relieve the other ISAs from 
> having
> to define this. Also, InOrder was the only core that was actively calling
> this function
> * * *
> isa: get rid of corespecific type
> The CoreSpecific type was used as a proxy to pass in HW specific params to
> a MIPS CPU, but since MIPS FS hasnt been touched for awhile, it makes sense
> to not force every other ISA to use CoreSpecific as well use a special
> reset function to set it. That probably should go in a PowerOn reset fault
>  anyway.
> 
> 
> Diffs
> -
> 
>   src/arch/alpha/isa.hh 6c9b532da0a6 
>   src/arch/alpha/types.hh 6c9b532da0a6 
>   src/arch/arm/types.hh 6c9b532da0a6 
>   src/arch/mips/isa.hh 6c9b532da0a6 
>   src/arch/mips/isa.cc 6c9b532da0a6 
>   src/arch/mips/types.hh 6c9b532da0a6 
>   src/arch/power/types.hh 6c9b532da0a6 
>   src/arch/sparc/types.hh 6c9b532da0a6 
>   src/arch/x86/types.hh 6c9b532da0a6 
>   src/cpu/BaseCPU.py 6c9b532da0a6 
>   src/cpu/base.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.hh 6c9b532da0a6 
>   src/cpu/inorder/cpu.cc 6c9b532da0a6 
> 
> Diff: http://reviews.m5sim.org/r/578/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Korey
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

2011-03-18 Thread Gabe Black


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/589/#review981
---



src/sim/syscall_emul.hh


Why is this change necessary? I'm not 100% sure why it was the way it was 
before, but I see no reason to change it either. Changing the fatal to a warn 
may be necessary to get some benchmark to run, but I'm talking specifically 
about the ones that would return -ENOTTY.


- Gabe


On 2011-03-17 16:06:13, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/589/
> ---
> 
> (Updated 2011-03-17 16:06:13)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86 ioctl:  Another patch from Vince Weaver
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
>   src/sim/syscall_emul.hh 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/589/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: patch from Vince Weaver for review

2011-03-18 Thread Gabe Black


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/588/#review980
---


It seems like we should be able to emulate the access system call fairly 
easily. It basically just checks if a file can be accessed in certain ways, I 
think. We could do that on the real file descriptor, rearrange the result if 
necessary, and pass it back. The other syscall changes here look ok.

- Gabe


On 2011-03-17 16:05:56, Lisa Hsu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/588/
> ---
> 
> (Updated 2011-03-17 16:05:56)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> X86:  SE syscalls: patch from Vince Weaver for review
> 
> 
> Diffs
> -
> 
>   src/arch/x86/linux/syscalls.cc 2e269d6fb3e6 
> 
> Diff: http://reviews.m5sim.org/r/588/diff
> 
> 
> Testing
> ---
> 
> I've done minimal testing on these, i.e. I've pushed them to a clean tree and 
> run X86 SPEC2k6 binaries on them, some of which didn't work prior to the 
> patches but now do.  Others remain broken.  Vince, however, has done lots of 
> testing and basically needed these to run SPEC2K workloads to completion for 
> his thesis.  In other words, I bet these patches are good, but not complete 
> for the purposes of running SPEC2k6.
> 
> 
> Thanks,
> 
> Lisa
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Hung up for a bit

2011-03-18 Thread Gabriel Michael Black

Hey folks. My computer decided to eat itself yesterday and my file  
system ended up mangled. I think the important stuff in my home  
directory survived, but I'm in a Starbucks right now trying to get it  
straightened out. Please give me a few days extra slack responding  
since I don't know when I'll be back up and running.


Gabe

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: ISA parser: Set up op_src_decl and op_dest_decl for pc operands.

2011-03-18 Thread Gabe Black



> On 2011-03-17 18:09:40, Korey Sewell wrote:
> > src/arch/isa_parser.py, line 184
> > 
> >
> > Hi Gabe, not to be nitpicky but what are you trying to accomplish with 
> > this change? 
> > 
> > I have no objection to it, I'm just trying to understand how this 
> > applies to a particular line of code in defining an instruction. 
> > 
> > Is there a short example you can provide that demonstrates what kind of 
> > ISA-description you will be able to use with this?

This fixes a bug in the earlier support I added that integrates the new PCState 
stuff into the ISA parser. If you use op_decl then everything would be fine, 
but if you use op_src_decl or op_dest_decl then the declaration I'm adding in 
here will be missing and it won't compile. I was adding some code as part of 
some other work I'm doing and ran into this, and the fix can be applied 
independently of that other code.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/587/#review970
---


On 2011-03-17 14:51:31, Gabe Black wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/587/
> ---
> 
> (Updated 2011-03-17 14:51:31)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> ISA parser: Set up op_src_decl and op_dest_decl for pc operands.
> 
> 
> Diffs
> -
> 
>   src/arch/isa_parser.py 5138d1e453f1 
> 
> Diff: http://reviews.m5sim.org/r/587/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gabe
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: SLICC: Remove external_type for structures

2011-03-18 Thread Nilay Vaish

changeset 9a6a02a235f1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9a6a02a235f1
description:
SLICC: Remove external_type for structures
In SLICC, in order to define a type a data type for which it should not
generate any code, the keyword external_type is used. For those data 
types for
which code should be generated, the keyword structure is used. This 
patch
eliminates the use of keyword external_type for defining structures. 
structure
key word can now have an optional attribute external, which would be 
used for
figuring out whether or not to generate the code for this structure. 
Also, now
structures can have functions as well data members in them.

diffstat:

 src/mem/protocol/MESI_CMP_directory-L1cache.sm  |   2 +-
 src/mem/protocol/MESI_CMP_directory-L2cache.sm  |   2 +-
 src/mem/protocol/MESI_CMP_directory-dir.sm  |   2 +-
 src/mem/protocol/MESI_CMP_directory-dma.sm  |   2 +-
 src/mem/protocol/MI_example-cache.sm|   2 +-
 src/mem/protocol/MI_example-dir.sm  |   2 +-
 src/mem/protocol/MOESI_CMP_directory-L1cache.sm |   2 +-
 src/mem/protocol/MOESI_CMP_directory-L2cache.sm |   4 +-
 src/mem/protocol/MOESI_CMP_directory-dir.sm |   2 +-
 src/mem/protocol/MOESI_CMP_directory-dma.sm |   4 +-
 src/mem/protocol/MOESI_CMP_token-L1cache.sm |   4 +-
 src/mem/protocol/MOESI_CMP_token-L2cache.sm |   4 +-
 src/mem/protocol/MOESI_CMP_token-dir.sm |   4 +-
 src/mem/protocol/MOESI_CMP_token-dma.sm |   2 +-
 src/mem/protocol/MOESI_hammer-cache.sm  |   2 +-
 src/mem/protocol/MOESI_hammer-dir.sm|   2 +-
 src/mem/protocol/RubySlicc_Exports.sm   |   2 +-
 src/mem/protocol/RubySlicc_Types.sm |  25 +--
 src/mem/slicc/parser.py |  26 +---
 19 files changed, 38 insertions(+), 57 deletions(-)

diffs (truncated from 388 to 300 lines):

diff -r 099771c7725d -r 9a6a02a235f1 
src/mem/protocol/MESI_CMP_directory-L1cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L1cache.smFri Mar 18 14:12:03 
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-L1cache.smFri Mar 18 14:12:04 
2011 -0500
@@ -119,7 +119,7 @@
 int pendingAcks, default="0", desc="number of pending acks";
   }
 
-  external_type(TBETable) {
+  structure(TBETable, external="yes") {
 TBE lookup(Address);
 void allocate(Address);
 void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 
src/mem/protocol/MESI_CMP_directory-L2cache.sm
--- a/src/mem/protocol/MESI_CMP_directory-L2cache.smFri Mar 18 14:12:03 
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-L2cache.smFri Mar 18 14:12:04 
2011 -0500
@@ -145,7 +145,7 @@
 int pendingAcks,desc="number of pending acks for invalidates 
during writeback";
   }
 
-  external_type(TBETable) {
+  structure(TBETable, external="yes") {
 TBE lookup(Address);
 void allocate(Address);
 void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MESI_CMP_directory-dir.sm
--- a/src/mem/protocol/MESI_CMP_directory-dir.smFri Mar 18 14:12:03 
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-dir.smFri Mar 18 14:12:04 
2011 -0500
@@ -95,7 +95,7 @@
 int Len,   desc="...";
   }
 
-  external_type(TBETable) {
+  structure(TBETable, external="yes") {
 TBE lookup(Address);  
 void allocate(Address); 
 void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MESI_CMP_directory-dma.sm
--- a/src/mem/protocol/MESI_CMP_directory-dma.smFri Mar 18 14:12:03 
2011 -0500
+++ b/src/mem/protocol/MESI_CMP_directory-dma.smFri Mar 18 14:12:04 
2011 -0500
@@ -20,7 +20,7 @@
 Ack,  desc="DMA write to memory completed";
   }
 
-  external_type(DMASequencer) {
+  structure(DMASequencer, external="yes") {
 void ackCallback();
 void dataCallback(DataBlock);
   }
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MI_example-cache.sm
--- a/src/mem/protocol/MI_example-cache.sm  Fri Mar 18 14:12:03 2011 -0500
+++ b/src/mem/protocol/MI_example-cache.sm  Fri Mar 18 14:12:04 2011 -0500
@@ -61,7 +61,7 @@
 DataBlock DataBlk,   desc="data for the block, required for concurrent 
writebacks";
   }
 
-  external_type(TBETable) {
+  structure(TBETable, external="yes") {
 TBE lookup(Address);
 void allocate(Address);
 void deallocate(Address);
diff -r 099771c7725d -r 9a6a02a235f1 src/mem/protocol/MI_example-dir.sm
--- a/src/mem/protocol/MI_example-dir.smFri Mar 18 14:12:03 2011 -0500
+++ b/src/mem/protocol/MI_example-dir.smFri Mar 18 14:12:04 2011 -0500
@@ -66,7 +66,7 @@
 MachineID DmaRequestor, desc="DMA requestor";
   }
 
-  external_type(TBETable) {
+  structure(TBETable, external="yes") {
 TBE lookup(Address);
 void allocate(Address);
 void deallocate(Address);
diff -r 099

[m5-dev] changeset in m5: SLICC: Remove the keyword wake_up_dependents

2011-03-18 Thread Nilay Vaish

changeset 099771c7725d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=099771c7725d
description:
SLICC: Remove the keyword wake_up_dependents
In order to add stall and wait facility for protocols, a keyword
wake_up_dependents was introduced. This patch removes the keyword,
instead this functionality is now implemented as function call.

diffstat:

 src/mem/protocol/MOESI_CMP_token-L1cache.sm   |   3 +-
 src/mem/protocol/MOESI_hammer-cache.sm|   3 +-
 src/mem/protocol/MOESI_hammer-dir.sm  |   3 +-
 src/mem/slicc/ast/WakeUpDependentsStatementAST.py |  46 ---
 src/mem/slicc/parser.py   |   5 --
 src/mem/slicc/symbols/StateMachine.py |  24 ++-
 6 files changed, 19 insertions(+), 65 deletions(-)

diffs (168 lines):

diff -r f3d1493787d4 -r 099771c7725d src/mem/protocol/MOESI_CMP_token-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_token-L1cache.sm   Fri Mar 18 14:12:01 
2011 -0500
+++ b/src/mem/protocol/MOESI_CMP_token-L1cache.sm   Fri Mar 18 14:12:03 
2011 -0500
@@ -177,6 +177,7 @@
   void set_tbe(TBE b);
   void unset_tbe();
   void wakeUpAllBuffers();
+  void wakeUpBuffers(Address a);
 
   TBETable L1_TBEs, template_hack="";
 
@@ -1522,7 +1523,7 @@
   }
 
   action(kd_wakeUpDependents, "kd", desc="wake-up dependents") {
-wake_up_dependents(address);
+wakeUpBuffers(address);
   }
 
   action(ka_wakeUpAllDependents, "ka", desc="wake-up all dependents") {
diff -r f3d1493787d4 -r 099771c7725d src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 14:12:01 2011 -0500
+++ b/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 14:12:03 2011 -0500
@@ -159,6 +159,7 @@
   void set_tbe(TBE b);
   void unset_tbe();
   void wakeUpAllBuffers();
+  void wakeUpBuffers(Address a);
 
   Entry getCacheEntry(Address address), return_by_pointer="yes" {
 Entry L2cache_entry := static_cast(Entry, "pointer", 
L2cacheMemory.lookup(address));
@@ -1013,7 +1014,7 @@
   }
 
   action(kd_wakeUpDependents, "kd", desc="wake-up dependents") {
-wake_up_dependents(address);
+wakeUpBuffers(address);
   }
 
   action(ka_wakeUpAllDependents, "ka", desc="wake-up all dependents") {
diff -r f3d1493787d4 -r 099771c7725d src/mem/protocol/MOESI_hammer-dir.sm
--- a/src/mem/protocol/MOESI_hammer-dir.sm  Fri Mar 18 14:12:01 2011 -0500
+++ b/src/mem/protocol/MOESI_hammer-dir.sm  Fri Mar 18 14:12:03 2011 -0500
@@ -173,6 +173,7 @@
   void unset_cache_entry();
   void set_tbe(TBE a);
   void unset_tbe();
+  void wakeUpBuffers(Address a);
 
   // ** OBJECTS **
 
@@ -1013,7 +1014,7 @@
   }
 
   action(k_wakeUpDependents, "k", desc="wake-up dependents") {
-wake_up_dependents(address);
+wakeUpBuffers(address);
   }
 
   action(l_popMemQueue, "q", desc="Pop off-chip request queue") {
diff -r f3d1493787d4 -r 099771c7725d 
src/mem/slicc/ast/WakeUpDependentsStatementAST.py
--- a/src/mem/slicc/ast/WakeUpDependentsStatementAST.py Fri Mar 18 14:12:01 
2011 -0500
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,46 +0,0 @@
-# Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
-# Copyright (c) 2009 The Hewlett-Packard Development Company
-# Copyright (c) 2010 Advanced Micro Devices, Inc.
-# 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.
-
-from slicc.ast.StatementAST import StatementAST
-
-class WakeUpDependentsStatementAST(StatementAST):
-def __init__(self, slicc, address):
-super(StatementAST, self

[m5-dev] changeset in m5: SLICC: Remove the keyword wake_up_all_dependents

2011-03-18 Thread Nilay Vaish

changeset f3d1493787d4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f3d1493787d4
description:
SLICC: Remove the keyword wake_up_all_dependents
In order to add stall and wait facility for protocols, a keyword
wake_up_all_dependents was introduced. This patch removes the keyword,
instead this functionality is now implemented as function call.

diffstat:

 src/mem/protocol/MOESI_CMP_token-L1cache.sm  |   3 +-
 src/mem/protocol/MOESI_hammer-cache.sm   |   3 +-
 src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py |  43 
 src/mem/slicc/parser.py  |   5 --
 src/mem/slicc/symbols/StateMachine.py|  40 +
 5 files changed, 25 insertions(+), 69 deletions(-)

diffs (160 lines):

diff -r e641f702653a -r f3d1493787d4 src/mem/protocol/MOESI_CMP_token-L1cache.sm
--- a/src/mem/protocol/MOESI_CMP_token-L1cache.sm   Fri Mar 18 11:47:15 
2011 -0700
+++ b/src/mem/protocol/MOESI_CMP_token-L1cache.sm   Fri Mar 18 14:12:01 
2011 -0500
@@ -176,6 +176,7 @@
   void unset_cache_entry();
   void set_tbe(TBE b);
   void unset_tbe();
+  void wakeUpAllBuffers();
 
   TBETable L1_TBEs, template_hack="";
 
@@ -1525,7 +1526,7 @@
   }
 
   action(ka_wakeUpAllDependents, "ka", desc="wake-up all dependents") {
-wake_up_all_dependents();
+wakeUpAllBuffers();
   }
 
   //*
diff -r e641f702653a -r f3d1493787d4 src/mem/protocol/MOESI_hammer-cache.sm
--- a/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 11:47:15 2011 -0700
+++ b/src/mem/protocol/MOESI_hammer-cache.smFri Mar 18 14:12:01 2011 -0500
@@ -158,6 +158,7 @@
   void unset_cache_entry();
   void set_tbe(TBE b);
   void unset_tbe();
+  void wakeUpAllBuffers();
 
   Entry getCacheEntry(Address address), return_by_pointer="yes" {
 Entry L2cache_entry := static_cast(Entry, "pointer", 
L2cacheMemory.lookup(address));
@@ -1016,7 +1017,7 @@
   }
 
   action(ka_wakeUpAllDependents, "ka", desc="wake-up all dependents") {
-wake_up_all_dependents();
+wakeUpAllBuffers();
   }
 
   //*
diff -r e641f702653a -r f3d1493787d4 
src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py
--- a/src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py  Fri Mar 18 
11:47:15 2011 -0700
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,43 +0,0 @@
-# Copyright (c) 1999-2008 Mark D. Hill and David A. Wood
-# Copyright (c) 2009 The Hewlett-Packard Development Company
-# Copyright (c) 2010 Advanced Micro Devices, Inc.
-# 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.
-
-from slicc.ast.StatementAST import StatementAST
-
-class WakeUpAllDependentsStatementAST(StatementAST):
-def __init__(self, slicc):
-super(StatementAST, self).__init__(slicc)
-
-def __repr__(self):
-return "[WakeUpAllDependentsStatementAst: %r]" % self.variable
-
-def generate(self, code, return_type):
-code('''
-if (m_waiting_buffers.size() > 0) {
-wakeUpAllBuffers();
-}
-''')
diff -r e641f702653a -r f3d1493787d4 src/mem/slicc/parser.py
--- a/src/mem/slicc/parser.py   Fri Mar 18 11:47:15 2011 -0700
+++ b/src/mem/slicc/parser.py   Fri Mar 18 14:12:01 2011 -0500
@@ -160,7 +160,6 @@
 'peek' : 'PEEK',
 'stall_and_wait' : 'STALL_AND_WAIT',
 'wake_up_dependents' : 'WAKE_UP_DEPENDENTS',
-'wake_up_all_dependents' : 'WAKE_UP_ALL_DEPENDE

[m5-dev] changeset in m5: base: disable FastAlloc in debug builds by default

2011-03-18 Thread Steve Reinhardt

changeset a6052f50deed in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a6052f50deed
description:
base: disable FastAlloc in debug builds by default
FastAlloc's reuse policies can mask allocation bugs, so
we typically want it disabled when debugging.  Set
FORCE_FAST_ALLOC to enable even when debugging, and set
NO_FAST_ALLOC to disable even in non-debug builds.

diffstat:

 SConstruct |6 +-
 src/base/fast_alloc.cc |  156 +
 src/base/fast_alloc.hh |   43 +++--
 3 files changed, 16 insertions(+), 189 deletions(-)

diffs (276 lines):

diff -r ed9c6b16e977 -r a6052f50deed SConstruct
--- a/SConstructThu Mar 17 19:24:37 2011 -0500
+++ b/SConstructFri Mar 18 11:47:11 2011 -0700
@@ -822,8 +822,8 @@
  sorted(n for n,m in CpuModel.dict.iteritems() if m.default),
  sorted(CpuModel.list)),
 BoolVariable('NO_FAST_ALLOC', 'Disable fast object allocator', False),
-BoolVariable('FAST_ALLOC_DEBUG', 'Enable fast object allocator debugging',
- False),
+BoolVariable('FORCE_FAST_ALLOC',
+ 'Enable fast object allocator, even for m5.debug', False),
 BoolVariable('FAST_ALLOC_STATS', 'Enable fast object allocator statistics',
  False),
 BoolVariable('EFENCE', 'Link with Electric Fence malloc debugger',
@@ -844,7 +844,7 @@
 
 # These variables get exported to #defines in config/*.hh (see src/SConscript).
 export_vars += ['FULL_SYSTEM', 'USE_FENV', 'USE_MYSQL',
-'NO_FAST_ALLOC', 'FAST_ALLOC_DEBUG', 'FAST_ALLOC_STATS',
+'NO_FAST_ALLOC', 'FORCE_FAST_ALLOC', 'FAST_ALLOC_STATS',
 'SS_COMPATIBLE_FP', 'USE_CHECKER', 'TARGET_ISA', 'CP_ANNOTATE',
 'USE_POSIX_CLOCK' ]
 
diff -r ed9c6b16e977 -r a6052f50deed src/base/fast_alloc.cc
--- a/src/base/fast_alloc.ccThu Mar 17 19:24:37 2011 -0500
+++ b/src/base/fast_alloc.ccFri Mar 18 11:47:11 2011 -0700
@@ -38,7 +38,7 @@
 
 #include "base/fast_alloc.hh"
 
-#if !NO_FAST_ALLOC
+#if USE_FAST_ALLOC
 
 #ifdef __GNUC__
 #pragma implementation
@@ -73,156 +73,4 @@
 return (p + sz);
 }
 
-#if FAST_ALLOC_DEBUG
-
-#include 
-#include 
-#include 
-
-#include "base/cprintf.hh"
-#include "sim/core.hh"   // for curTick()
-
-using namespace std;
-
-// count of in-use FastAlloc objects
-int FastAlloc::numInUse;
-
-// dummy head & tail object for doubly linked list of in-use FastAlloc
-// objects
-FastAlloc FastAlloc::inUseHead(&FastAlloc::inUseHead, &FastAlloc::inUseHead);
-
-// special constructor for dummy head: make inUsePrev & inUseNext
-// point to self
-FastAlloc::FastAlloc(FastAlloc *prev, FastAlloc *next)
-{
-inUsePrev = prev;
-inUseNext = next;
-}
-
-// constructor: marks as in use, add to in-use list
-FastAlloc::FastAlloc()
-{
-// mark this object in use
-inUse = true;
-whenAllocated = curTick();
-
-// update count
-++numInUse;
-
-// add to tail of list of in-use objects ("before" dummy head)
-FastAlloc *myNext = &inUseHead;
-FastAlloc *myPrev = inUseHead.inUsePrev;
-
-inUsePrev = myPrev;
-inUseNext = myNext;
-myPrev->inUseNext = this;
-myNext->inUsePrev = this;
-}
-
-// destructor: mark not in use, remove from in-use list
-FastAlloc::~FastAlloc()
-{
-assert(inUse);
-inUse = false;
-
---numInUse;
-assert(numInUse >= 0);
-
-// remove me from in-use list
-inUsePrev->inUseNext = inUseNext;
-inUseNext->inUsePrev = inUsePrev;
-}
-
-
-// Note that in all the display functions below we suppress anything
-// with a zero allocation timestamp... there are a bunch of static or
-// quasi-static structures that get allocated during initialization
-// and we generally don't care about them so this gets them out of the
-// way.
-
-// summarize in-use list
-void
-FastAlloc::dump_summary()
-{
-map typemap;
-
-for (FastAlloc *p = inUseHead.inUseNext; p != &inUseHead; p = p->inUseNext)
-{
-if (p->whenAllocated != 0)
-++typemap[typeid(*p).name()];
-}
-
-map::const_iterator mapiter;
-
-cprintf(" count  type\n"
-" -  \n");
-for (mapiter = typemap.begin(); mapiter != typemap.end(); ++mapiter)
-cprintf("%6d  %s\n",mapiter->second, mapiter->first);
-}
-
-
-// show oldest n items on in-use list
-void
-FastAlloc::dump_oldest(int n)
-{
-// sanity check: don't want to crash the debugger if you forget to
-// pass in a parameter
-if (n < 0 || n > numInUse) {
-cprintf("FastAlloc::dump_oldest: bad arg %d (%d objects in use)\n",
-n, numInUse);
-return;
-}
-
-for (FastAlloc *p = inUseHead.inUseNext;
- p != &inUseHead && n > 0;
- p = p->inUseNext, --n) {
-if (p->whenAllocated != 0)
-cprintf("%x %15d %s\n", p, p->whenAllocated, typeid(*p).name());
-}
-}
-
-
-// show oldest n items

[m5-dev] changeset in m5: swig: get rid of m5.internal.random module (swi...

2011-03-18 Thread Steve Reinhardt

changeset e641f702653a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e641f702653a
description:
swig: get rid of m5.internal.random module (swig/random.i)
Thanks to swig this was interfering with the standard Python
random module.  The only function in that module was seed(),
which erroneously called srand48().  Moved the function to
m5.internal.core, renamed it seedRandom(), and made it call
random_mt.init() instead.

diffstat:

 src/python/SConscript|   1 -
 src/python/swig/core.i   |   9 
 src/python/swig/random.i |  49 
 3 files changed, 9 insertions(+), 50 deletions(-)

diffs (97 lines):

diff -r a6052f50deed -r e641f702653a src/python/SConscript
--- a/src/python/SConscript Fri Mar 18 11:47:11 2011 -0700
+++ b/src/python/SConscript Fri Mar 18 11:47:15 2011 -0700
@@ -65,7 +65,6 @@
 SwigSource('m5.internal', 'swig/core.i')
 SwigSource('m5.internal', 'swig/debug.i')
 SwigSource('m5.internal', 'swig/event.i')
-SwigSource('m5.internal', 'swig/random.i')
 SwigSource('m5.internal', 'swig/range.i')
 SwigSource('m5.internal', 'swig/stats.i')
 SwigSource('m5.internal', 'swig/trace.i')
diff -r a6052f50deed -r e641f702653a src/python/swig/core.i
--- a/src/python/swig/core.iFri Mar 18 11:47:11 2011 -0700
+++ b/src/python/swig/core.iFri Mar 18 11:47:15 2011 -0700
@@ -35,6 +35,7 @@
 #include "python/swig/pyobject.hh"
 
 #include "base/misc.hh"
+#include "base/random.hh"
 #include "base/socket.hh"
 #include "base/types.hh"
 #include "sim/core.hh"
@@ -54,6 +55,13 @@
 const bool flag_TRACING_ON = TRACING_ON;
 
 inline void disableAllListeners() { ListenSocket::disableAll(); }
+
+inline void
+seedRandom(uint64_t seed)
+{
+random_mt.init(seed);
+}
+
 %}
 
 %include 
@@ -64,6 +72,7 @@
 void setOutputDir(const std::string &dir);
 void doExitCleanup();
 void disableAllListeners();
+void seedRandom(uint64_t seed);
 
 %immutable compileDate;
 char *compileDate;
diff -r a6052f50deed -r e641f702653a src/python/swig/random.i
--- a/src/python/swig/random.i  Fri Mar 18 11:47:11 2011 -0700
+++ /dev/null   Thu Jan 01 00:00:00 1970 +
@@ -1,49 +0,0 @@
-/*
- * Copyright (c) 2006 The Regents of The University of Michigan
- * 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: Nathan Binkert
- */
-
-%module(package="m5.internal") random
-
-%include 
-
-%{
-#include 
-
-#include "base/types.hh"
-
-inline void
-seed(uint64_t seed)
-{
-::srand48(seed & ULL(0x));
-}
-%}
-
-%inline %{
-extern void seed(uint64_t seed);
-%}
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-18 Thread Malek Musleh

Hi Korey,

I don't seem to have encountered that deadlock threshold when booting
the old changeset. I tried both 16 + 20 core configurations just now
and they seem to work. Although, they do take a really really long
time compared to ~1-4 cores.

I have also tried previously booting 64 cores, some time ago, and that
also worked, but that took several hours.

In general though, that threshold is just a fixed number, and as the
CMP machine gets bigger, the 5 seems to be way too low, and would
have to be multiplied by a factor of 2 -3?

I tried using the default crossbar topology, maybe you encounter the
deadlock threshold using Mesh?

Malek

On Fri, Mar 18, 2011 at 12:12 PM, Korey Sewell  wrote:
> 
>
> Why did it work before the block size patch?
>> - When the ChuckGenerator sees the block size is 0, it doesn't split up the
>> request into multiple patches and sends the whole dma request at once.  That
>> is fine because the DMASequencer splits the request into multiple requests
>> and only responds to the dma port when the entire request is complete.
>>
> With regards to the old changeset that boots with the block size = 0, I was
> not able to boot a large scale CMP system (more than 16 cores) due to the
> "deadlock threshold" being triggered.
>
> I'm assuming that Brad has a read on how to fix that problem so I'll
> probably start working on what is causing that deadlock so hopefully we can
> kind of pipeline the bug fixes.
>
> --
> - Korey
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Ruby FS - DMA Controller problem?

2011-03-18 Thread Korey Sewell



Why did it work before the block size patch?
> - When the ChuckGenerator sees the block size is 0, it doesn't split up the
> request into multiple patches and sends the whole dma request at once.  That
> is fine because the DMASequencer splits the request into multiple requests
> and only responds to the dma port when the entire request is complete.
>
With regards to the old changeset that boots with the block size = 0, I was
not able to boot a large scale CMP system (more than 16 cores) due to the
"deadlock threshold" being triggered.

I'm assuming that Brad has a read on how to fix that problem so I'll
probably start working on what is causing that deadlock so hopefully we can
kind of pipeline the bug fixes.

-- 
- Korey
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-18 Thread Ali Saidi



> On 2011-02-27 21:41:48, Gabe Black wrote:
> > Should we put an assert in there to make sure no access is bigger than 16 
> > bytes? Also what about unaligned accesses? I think those will be split on 
> > cache block boundaries which may be bigger or smaller than 16 bytes. We 
> > might have an access that spans from one 16 byte chunk to the next. These 
> > aren't really problems with this change, but it might make them easier to 
> > hit.
> > 
> > I'm assuming this had some effect on the regressions. Did things generally 
> > go faster, slower, etc.?
> 
> Ali Saidi wrote:
> Not major changes, but things usually sped up a little bit.

Actually it is quite a change for some benchmarks, it's just not uniform. High 
of 17%, low of 0%, average of about 5%. So I think we need to fix it and if it 
exposes other bugs, so be it, but the regression tests all complete 
successfully. 

alpha
--
eon: 17%
twolf: 15%
vortex: 5%
gzip 0%
linux: 0%
bzip2: 3%
perlbmk: 2%


parc

gzip: 3%

x86

mcf: 17%
parser: 4%
twolf: 2%
gzip: 2%

arm
--
gzip: 7%
mcf: 2%
eon: 13%
twolf: 3%
parser: 3%
vortex: 6%
perlbmk: 
bzip2:
linux: 1%


- Ali


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review915
---


On 2011-02-27 18:52:51, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-02-27 18:52:51)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Cron /z/m5/regression/do-regression quick

2011-03-18 Thread Cron Daemon

scons: *** Source 
`tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/stats.txt' 
not found, needed by target 
`build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer/status'.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
 passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
 passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/SPARC_SE/tests/fast/quick/02.ins

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

[m5-dev] Review Request: Ruby: Convert CacheRequestType to RubyRequestType

[m5-dev] Review Request: Ruby: Convert AccessModeType to RubyAccessMode

Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst

Re: [m5-dev] Review Request: se.py: Modify script to make multiprogramming much easier.

Re: [m5-dev] Review Request: configs: combine ruby_se.py and se.py to avoid all that code duplication

Re: [m5-dev] Review Request: enable x86 workloads on se.py

Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst

Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC

[m5-dev] Review Request: configs: combine ruby_se.py and se.py to avoid all that code duplication

[m5-dev] Review Request: enable x86 workloads on se.py

[m5-dev] Review Request: se.py: Modify script to make multiprogramming much easier.

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

Re: [m5-dev] Review Request: sparc: compilation fixes for inorder

Re: [m5-dev] Review Request: isa: get rid of expandForMT function

Re: [m5-dev] Review Request: X86 ioctl: Another patch from Vince Weaver

Re: [m5-dev] Review Request: patch from Vince Weaver for review

[m5-dev] Hung up for a bit

Re: [m5-dev] Review Request: ISA parser: Set up op_src_decl and op_dest_decl for pc operands.

[m5-dev] changeset in m5: SLICC: Remove external_type for structures

[m5-dev] changeset in m5: SLICC: Remove the keyword wake_up_dependents

[m5-dev] changeset in m5: SLICC: Remove the keyword wake_up_all_dependents

[m5-dev] changeset in m5: base: disable FastAlloc in debug builds by default

[m5-dev] changeset in m5: swig: get rid of m5.internal.random module (swi...

Re: [m5-dev] Ruby FS - DMA Controller problem?

Re: [m5-dev] Ruby FS - DMA Controller problem?

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

[m5-dev] Cron /z/m5/regression/do-regression quick

30 matches

Site Navigation

Mail list logo

Footer information