[gem5-dev] possible bug in ruby/common/Set.hh

2011-05-28 Thread Tushar Krishna

Hi all,

I think src/mem/ruby/common/Set.hh has a bug.

It has the following lines:
static const int LONG_BITS = std::numeric_limitslong::digits;
static const int INDEX_SHIFT = LONG_BITS == 64 ? 6 : 5;

Since long by default is signed, LONG_BITS will always be 31 or 63, 
depending on the machine (not 32 or 64).

This means that INDEX_SHIFT will always be set to 5.

I tried setting --num-cpus to 128 and ran a tester, and observed a bunch 
of glibc errors.

A gdb backtrace pointed me to Set.hh (via ruby/common/NetDest.hh).
I changed long to unsigned long and that fixed the issue.

Is this a fine fix and should I send out a patch?

Thanks,
Tushar


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


Re: [gem5-dev] possible bug in ruby/common/Set.hh

2011-05-28 Thread Korey Sewell
Tushar,
There should be an earlier thread about this issue (or one very similar). A
symptom of this issue is the inability to run large systems on 32-bit
machines.

I think what we wanted to do is use STL bitsets here (check that thread for
details). I would do it myself but I wont have time until after the tutorial
for Ruby optimizations.

Could you check that thread and let us know whether that would or would not
solve this problem?

On Sat, May 28, 2011 at 2:21 AM, Tushar Krishna tus...@csail.mit.eduwrote:

 Hi all,

 I think src/mem/ruby/common/Set.hh has a bug.

 It has the following lines:
static const int LONG_BITS = std::numeric_limitslong::digits;
static const int INDEX_SHIFT = LONG_BITS == 64 ? 6 : 5;

 Since long by default is signed, LONG_BITS will always be 31 or 63,
 depending on the machine (not 32 or 64).
 This means that INDEX_SHIFT will always be set to 5.

 I tried setting --num-cpus to 128 and ran a tester, and observed a bunch of
 glibc errors.
 A gdb backtrace pointed me to Set.hh (via ruby/common/NetDest.hh).
 I changed long to unsigned long and that fixed the issue.

 Is this a fine fix and should I send out a patch?

 Thanks,
 Tushar


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




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


Re: [gem5-dev] possible bug in ruby/common/Set.hh

2011-05-28 Thread Tushar Krishna

Thanks Korey.
Yeah inability to run  32 cores on 32-bit machines, and inability to 
run  64 cores on 64-bit machines is the same issue, so I guess the STL 
bitsets solution should fix this problem too.


Thanks,
Tushar

On 5/28/2011 2:34 AM, Korey Sewell wrote:

Tushar,
There should be an earlier thread about this issue (or one very similar). A
symptom of this issue is the inability to run large systems on 32-bit
machines.

I think what we wanted to do is use STL bitsets here (check that thread for
details). I would do it myself but I wont have time until after the tutorial
for Ruby optimizations.

Could you check that thread and let us know whether that would or would not
solve this problem?

On Sat, May 28, 2011 at 2:21 AM, Tushar Krishnatus...@csail.mit.eduwrote:


Hi all,

I think src/mem/ruby/common/Set.hh has a bug.

It has the following lines:
static const int LONG_BITS = std::numeric_limitslong::digits;
static const int INDEX_SHIFT = LONG_BITS == 64 ? 6 : 5;

Since long by default is signed, LONG_BITS will always be 31 or 63,
depending on the machine (not 32 or 64).
This means that INDEX_SHIFT will always be set to 5.

I tried setting --num-cpus to 128 and ran a tester, and observed a bunch of
glibc errors.
A gdb backtrace pointed me to Set.hh (via ruby/common/NetDest.hh).
I changed long to unsigned long and that fixed the issue.

Is this a fine fix and should I send out a patch?

Thanks,
Tushar


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





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


[gem5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick

2011-05-28 Thread Cron Daemon
scons: `build/ALPHA_SE/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_hammer/m5.debug' is up to date.
scons: `build/ALPHA_SE_MESI_CMP_directory/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.debug' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_token/m5.debug' is up to date.
scons: `build/ALPHA_FS/m5.debug' is up to date.
scons: `build/MIPS_SE/m5.debug' is up to date.
scons: `build/POWER_SE/m5.debug' is up to date.
scons: `build/SPARC_SE/m5.debug' is up to date.
scons: `build/SPARC_FS/m5.debug' is up to date.
scons: `build/X86_SE/m5.debug' is up to date.
scons: `build/X86_FS/m5.debug' is up to date.
scons: `build/ARM_SE/m5.debug' is up to date.
scons: `build/ARM_FS/m5.debug' is up to date.
scons: `build/ALPHA_SE/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_hammer/m5.fast' is up to date.
scons: `build/ALPHA_SE_MESI_CMP_directory/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.fast' is up to date.
scons: `build/ALPHA_SE_MOESI_CMP_token/m5.fast' is up to date.
scons: `build/ALPHA_FS/m5.fast' is up to date.
scons: `build/MIPS_SE/m5.fast' is up to date.
scons: `build/POWER_SE/m5.fast' is up to date.
scons: `build/SPARC_SE/m5.fast' is up to date.
scons: `build/SPARC_FS/m5.fast' is up to date.
scons: `build/X86_SE/m5.fast' is up to date.
scons: `build/X86_FS/m5.fast' is up to date.
scons: `build/ARM_SE/m5.fast' is up to date.
scons: `build/ARM_FS/m5.fast' is up to date.
scons: *** Source 
`tests/quick/00.hello/ref/alpha/tru64/simple-timing-ruby/stats.txt' not found, 
needed by target 
`build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby/status'.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed.
* build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 

Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Ali Saidi

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



src/python/m5/params.py
http://reviews.m5sim.org/r/720/#comment1746

The all proxy object is going to return an array which in then going to get 
turned into [[all,objects,that,match]]. we don't want this.



src/python/m5/proxy.py
http://reviews.m5sim.org/r/720/#comment1747

Parent.all would find every object above you in the hierarchy that matched, 
although I've never tried it. I only use self.all..

I can add a description for those two. Will you add one for the rest of the 
proxy objets? :)


- Ali


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Ali Saidi


 On 2011-05-26 23:29:05, Gabe Black wrote:
  What does Self.all do? What is it for? You have one use in the change so I 
  have a basic idea, but it would be helpful to know the specifics.
 
 Ali Saidi wrote:
 It's similar to Parent.any in that it traverses the object hierarchy and 
 finds all  (as opposed to one) objects that are of a certain type.  As you 
 see from the memories example, the system object can have a pointer to all 
 PhysicalMemory objects that belong to that system. The reason to add 
 something like this, is to have a generic way to prevent speculation from 
 touching I/O. It's possible for a speculative instruction fetch to sneak out 
 of the CPU if the wrong 10 things all happen an once and with this another 
 change can prevent that (will post soon). It's not as simple as just not 
 fetching from non-cacheable memory, since most architectures start their 
 processors in some kind of caches disabled, tlb should only issue 
 non-cachable transaction state.
 
 Steve Reinhardt wrote:
 So if the real machine is using speculative execution in this 
 cache-disable mode, how does it avoid touching I/O locations?

i would guess that when it sees non-cachable memory it only executes one 
instruction at a time or something, but that would be incredibly difficult to 
retrofit the o3 model to be able to do.


- Ali


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


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Ali Saidi


 On 2011-05-27 20:10:01, Nathan Binkert wrote:
  src/python/m5/SimObject.py, line 729
  http://reviews.m5sim.org/r/720/diff/1/?file=12673#file12673line729
 
  Does this do what you want?  It doesn't seem like it would recurse down 
  the tree and find all nodes that match (or does it?)

It works. I've been using it for 2 weeks without issues and all the regressions 
pass. 


- Ali


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


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Steve Reinhardt


 On 2011-05-28 09:20:00, Ali Saidi wrote:
  src/python/m5/proxy.py, line 187
  http://reviews.m5sim.org/r/720/diff/1/?file=12675#file12675line187
 
  Parent.all would find every object above you in the hierarchy that 
  matched, although I've never tried it. I only use self.all..
  
  I can add a description for those two. Will you add one for the rest of 
  the proxy objets? :)

After looking at BaseProxy.unproxy(), I'm pretty sure Parent.all will not work, 
since the base algorithm quits as soon as it sees a find() method return True.  
I don't think that's a huge problem, but it would be good to find a way to 
return an error on Parent.all instead of letting people find out the hard way 
that it doesn't work.


 On 2011-05-28 09:20:00, Ali Saidi wrote:
  src/python/m5/params.py, line 187
  http://reviews.m5sim.org/r/720/diff/1/?file=12674#file12674line187
 
  The all proxy object is going to return an array which in then going to 
  get turned into [[all,objects,that,match]]. we don't want this.

I understand why this code is necessary, but that doesn't mean I like it ;-).  
It seems like an arbitrary hack that could possibly turn around and bite us at 
some point.

Basically the current code assumes that a proxied VectorParam is a vector of 
scalar proxies, not a single proxy object that's going to return a vector of 
things.  This code assumes that if the first element of the unproxied vector is 
a vector, then you really want that and not the original vector.  Seems a 
little broad to me.  How about something like:

if len(self) == 1 and isinstance(self[0], AllProxy):
return self[0].unproxy(base)
else:
return [v.unproxy(base) for v in self]


- Steve


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


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Steve Reinhardt

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



src/sim/System.py
http://reviews.m5sim.org/r/720/#comment1750

It seems odd that Parent.any here will generate an error if there are 
multiple matches, but Self.all only is necessary if there are multiple matches. 
 I think the reason it's not a problem is that this Parent.any proxy on physmem 
is never used.  Should we get rid of it?


- Steve


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Ali Saidi


 On 2011-05-28 17:22:15, Steve Reinhardt wrote:
  src/sim/System.py, line 47
  http://reviews.m5sim.org/r/720/diff/1/?file=12676#file12676line47
 
  It seems odd that Parent.any here will generate an error if there are 
  multiple matches, but Self.all only is necessary if there are multiple 
  matches.  I think the reason it's not a problem is that this Parent.any 
  proxy on physmem is never used.  Should we get rid of it?

You mean we set it to something and we should make it have no default? Another 
option would be to change the way this works a bit. Just use the memories 
above. 


- Ali


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


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


Re: [gem5-dev] Review Request: Config: Add support for a Self.all proxy object

2011-05-28 Thread Steve Reinhardt


 On 2011-05-28 17:22:15, Steve Reinhardt wrote:
  src/sim/System.py, line 47
  http://reviews.m5sim.org/r/720/diff/1/?file=12676#file12676line47
 
  It seems odd that Parent.any here will generate an error if there are 
  multiple matches, but Self.all only is necessary if there are multiple 
  matches.  I think the reason it's not a problem is that this Parent.any 
  proxy on physmem is never used.  Should we get rid of it?
 
 Ali Saidi wrote:
 You mean we set it to something and we should make it have no default? 
 Another option would be to change the way this works a bit. Just use the 
 memories above.

Getting rid of the Parent.any default would be one step; merging physmem and 
memories would be even better since they seem redundant, correct?  What about 
keeping the physmem name and replacing it with the definition you have for 
memories?


- Steve


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


On 2011-05-26 19:17:18, Ali Saidi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/720/
 ---
 
 (Updated 2011-05-26 19:17:18)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Config: Add support for a Self.all proxy object
 
 
 Diffs
 -
 
   src/python/m5/SimObject.py 3f37cc5d25bc 
   src/python/m5/params.py 3f37cc5d25bc 
   src/python/m5/proxy.py 3f37cc5d25bc 
   src/sim/System.py 3f37cc5d25bc 
 
 Diff: http://reviews.m5sim.org/r/720/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Ali
 


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


[gem5-dev] Functional Memory Accesses in Ruby

2011-05-28 Thread Nilay Vaish

Hi Brad

I am trying to complete the patch on functional accesses in Ruby. I came 
across this problem while testing the patch for higher number of 
processors. I am working with MESI CMP directory protocol right now. So I 
will describe the problem in its context.


Assume we are trying to functionally write some thing to block A. It is in 
state S_I in the L2 cache. When a block moves to state S_I from state SS, 
then the cache block in the cache is deallocated. Therefore, when viewed 
from the CacheMemory's perpespective, since the cache does not have block 
A, therefore, the L2 cache is of no consequence for this access. But the 
controller has a TBE for this block. And this TBE will have this block 
with AccessPermission:Busy. Also, there are L1 caches in the system that 
hold this block in S state.


Now, as per the current condition for write functional accesses,

 if((num_busy == 0  num_ro  0) || num_rw == 1)

this access would go ahead as num_busy would evaluate to 0 and num_ro 
would evaluate to some value greater than 0. But clearly we do not want 
this access to be performed since that state S_I is a busy state and no 
other cache holds the block in a read-write state.


It seems to me that the controller should supply the function for deciding 
the access permissions, since it is possible that one the TBE holds the 
block.


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


Re: [gem5-dev] Review Request: Misc: Remove the URL from warnings, fatals, panics, etc.

2011-05-28 Thread Gabriel Michael Black

ping

Quoting Gabe Black gbl...@eecs.umich.edu:



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

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



Summary
---

Misc: Remove the URL from warnings, fatals, panics, etc.


Diffs
-

  src/base/misc.cc dda2a88eb7c4
  src/python/m5/util/__init__.py dda2a88eb7c4

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


Testing
---


Thanks,

Gabe

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





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


Re: [gem5-dev] [m5-dev] src/dest detection in the ISA descriptions

2011-05-28 Thread Gabriel Michael Black

ping

Quoting Gabe Black gbl...@eecs.umich.edu:


Ping...

On 05/05/11 10:38, Steve Reinhardt wrote:

On Wed, May 4, 2011 at 2:25 PM, Gabe Black gbl...@eecs.umich.edu wrote:


Did that make sense?


I see how that could work... I think I was more puzzled by how you would
figure out that

for (int i = 0; i  7; i++)
Dest.bytes[i] = Source1.bytes[i] + Source2.bytes[i];

overwrote all of Dest, but

for (int i = 0; i  4; i++)
Dest.bytes[i] = Source1.bytes[i] + Source2.bytes[i];

wouldn't... but looking back I see now that you'd expect to need manual
annotations in at least one of those cases.



Do you think you'll be able to review those patches
soonish?


I'll try... thanks for the reminder, that definitely increases the
probability :-).

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


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




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


Re: [gem5-dev] Review Request: Misc: Remove the URL from warnings, fatals, panics, etc.

2011-05-28 Thread Steve Reinhardt

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

Ship it!


- Steve


On 2011-05-25 09:25:20, Gabe Black wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/719/
 ---
 
 (Updated 2011-05-25 09:25:20)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 Misc: Remove the URL from warnings, fatals, panics, etc.
 
 
 Diffs
 -
 
   src/base/misc.cc dda2a88eb7c4 
   src/python/m5/util/__init__.py dda2a88eb7c4 
 
 Diff: http://reviews.m5sim.org/r/719/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Gabe
 


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


Re: [gem5-dev] Review Request: ISA parser: Simplify operand type handling.

2011-05-28 Thread Steve Reinhardt

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


The description is a little general; can you be more specific about what this 
change is doing?  I see that you're getting rid of the size from the memory 
access operands and encoding that in the ctype instead, which seems fine.  
However it seems like you've gotten rid of a lot of the signed vs. unsigned 
code, and made everything look unsigned, and I don't see how that still works.


src/arch/mips/isa/decoder.isa
http://reviews.m5sim.org/r/655/#comment1753

This confuses me... how is it that lb  lbu (and lh  lhu) have identical 
definitions now?  What is it that makes lb and lh signed?


- Steve


On 2011-04-25 03:03:53, Gabe Black wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/655/
 ---
 
 (Updated 2011-04-25 03:03:53)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ISA parser: Simplify operand type handling.
 
 This change simplifies the code surrounding operand type handling and makes it
 depend only on the ctype that goes with each operand type. Future changes will
 allow defining operand types by their ctypes directly, convert the ISAs over
 to that style of definition, and then remove support for the old style. These
 changes are to make it easier to use non-builtin types like classes or
 structures as the type for operands.
 
 
 Diffs
 -
 
   src/arch/alpha/isa/mem.isa de679a068dd8 
   src/arch/arm/isa/insts/ldr.isa de679a068dd8 
   src/arch/arm/isa/insts/mem.isa de679a068dd8 
   src/arch/arm/isa/insts/str.isa de679a068dd8 
   src/arch/arm/isa/templates/mem.isa de679a068dd8 
   src/arch/isa_parser.py de679a068dd8 
   src/arch/mips/isa/decoder.isa de679a068dd8 
   src/arch/mips/isa/formats/mem.isa de679a068dd8 
   src/arch/power/isa/decoder.isa de679a068dd8 
   src/arch/power/isa/formats/mem.isa de679a068dd8 
   src/arch/sparc/isa/decoder.isa de679a068dd8 
   src/arch/sparc/isa/formats/mem/swap.isa de679a068dd8 
   src/arch/sparc/isa/formats/mem/util.isa de679a068dd8 
 
 Diff: http://reviews.m5sim.org/r/655/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Gabe
 


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


Re: [gem5-dev] Review Request: ISA parser: Allow defining operand types with a ctype directly.

2011-05-28 Thread Steve Reinhardt

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


This looks fine to me, but I'm confused... don't you delete this code 
completely two patches from now?  Why bother changing it if you're going to get 
rid of it?

- Steve


On 2011-04-25 03:04:12, Gabe Black wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/656/
 ---
 
 (Updated 2011-04-25 03:04:12)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ISA parser: Allow defining operand types with a ctype directly.
 
 
 Diffs
 -
 
   src/arch/isa_parser.py de679a068dd8 
 
 Diff: http://reviews.m5sim.org/r/656/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Gabe
 


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


Re: [gem5-dev] Review Request: X86: Convert operand types to the new style.

2011-05-28 Thread Steve Reinhardt

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


Looks fine, but shouldn't you be doing all the ISAs if you're going to get rid 
of the old style?

- Steve


On 2011-04-25 03:04:20, Gabe Black wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/657/
 ---
 
 (Updated 2011-04-25 03:04:20)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 X86: Convert operand types to the new style.
 
 
 Diffs
 -
 
   src/arch/x86/isa/operands.isa de679a068dd8 
 
 Diff: http://reviews.m5sim.org/r/657/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Gabe
 


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


Re: [gem5-dev] Review Request: ISA parser: Stop supporting the old style operand types.

2011-05-28 Thread Steve Reinhardt

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


See previous reviews... this looks fine if all the ISAs are converted to use 
it.  Once it's committed, the relevant documentation should also be updated 
(e.g., http://gem5.org/Code_parsing#Operand_type_qualifiers).

- Steve


On 2011-04-25 03:04:33, Gabe Black wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/658/
 ---
 
 (Updated 2011-04-25 03:04:33)
 
 
 Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
 Nathan Binkert.
 
 
 Summary
 ---
 
 ISA parser: Stop supporting the old style operand types.
 
 
 Diffs
 -
 
   src/arch/isa_parser.py de679a068dd8 
 
 Diff: http://reviews.m5sim.org/r/658/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Gabe
 


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