Re: [gem5-dev] Review Request: SConstruct: automatically update .hg/hgrc with style hooks

[Gabe Black]

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



SConstruct


This is pretty reasonable, but it would be nice to mention that if it's not 
OK you can use Ctrl+C to get out of it. Usually Ctrl+C is a fairly drastic last 
resort, so people might not think to use it.


- Gabe


On 2011-06-01 21:27:23, Steve Reinhardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/668/
> ---
> 
> (Updated 2011-06-01 21:27:23)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> SConstruct: automatically update .hg/hgrc with style hooks
> 
> Seems easier than pestering people about it.
> Note also that path is now absolute, so you don't get errors
> when invoking hg from subdirectories.
> 
> 
> Diffs
> -
> 
>   SConstruct 3f49ed206f46 
> 
> Diff: http://reviews.m5sim.org/r/668/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steve
> 
>

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

Re: [gem5-dev] Debug Flags

[nathan binkert]

I'll post a diff to fix the SCons stuff very soon.  Just compiling
stuff to make sure it works.

The biggest problem with two namespaces is that it's a lot of code to
manage to support both of them.  The debug flags stuff is all over the
place: scons to generate the flags files, command line options, gdb
commands, C++ classes, and probably more.  I think we'll be able to
work through the confusion.

  Nate

On Wed, Jun 1, 2011 at 9:40 PM, Steve Reinhardt  wrote:
> OK, now that I'm at a keyboard: if we change the scons thing from
> TraceFlag() to DebugFlag(), then there's one set of flags with one set
> of names, it's all debug flags.  Some (currently most) of them are
> only used to control DPRINTFs, but they could be used for other
> things, and the same flag could in theory be used for both DPRINTFs
> and other things.
>
> All the --trace-* options solely control things related to DPRINTFs
> and/or exec tracing (I believe), so that's consistent too.
>
> It might not be the simplest scheme ever, but it sounds simpler than
> having distinct debug flags and trace flags.
>
> Steve
>
> On Wed, Jun 1, 2011 at 8:15 PM, Steve Reinhardt  wrote:
>> On my phone, so I'll be brief, but just fixing the scons to be consistent
>> sounds good to me.
>>
>> On Jun 1, 2011 6:55 PM, "Gabriel Michael Black" 
>> wrote:
>>> So, I think part of the confusion is that there are two names now,
>>> debug flags and trace flags, but they're different views of the same
>>> mechanism (yes? no?) It seems like the --trace* options are like the
>>> --debug* options, except their intended use is a subset of --debug*,
>>> specifically DPRINTFs. What about returning the DPRINTF ones to
>>> --trace-flags, etc., and introducing a separate parallel set of
>>> options and namespace for the debug stuff? There's some macro or
>>> something to check if trace flags are turned on, and that encourages
>>> their use as debug flags (although I think that use is minimal in the
>>> current code). We could introduce a new DEBUG_ON() macro (or a better
>>> name) and optionally eliminate the trace oriented one or make it
>>> internal to DPRINTFs only. I can think of some valid uses for keeping
>>> it like blocks of DPRINTFs like Ali added recently, but it blurs the
>>> line and could add to the confusion.
>>>
>>> By having two parallel systems, even though they're a bit redundant
>>> where they overlap, I think it introduces a clear conceptual
>>> separation between the two. Then it's clear what trace flags are for
>>> and when to use them, and also what debug flags are for and when to
>>> use them.
>>>
>>> We really have two different ideas budding off from each other
>>> (controlling tracing and debug features), and by partially bundling
>>> them together and partially distinguishing them that leads to
>>> confusion. The mental model is different from the way you have to
>>> control things, and trying to reconcile the two views makes the system
>>> hard to reason about.
>>>
>>> Gabe
>>>
>>> Quoting nathan binkert :
>>>
 Ok, there has been a lot of confusion about debug flags and trace
 flags. I changed the way the flags stuff worked from a compile
 perspective which required me to make changes throughout the tree, so
 I took the opportunity to rename the trace flags to debug flags. The
 idea behind the change was that the flags can be used for things other
 than tracing (I use them for breakpoints) and there is only one
 namespace, so I just renamed it to debug (people did review that
 change).

 So, I renamed --trace-flags to --debug-flags and --trace-flags-help to
 --debug-flags-help. --trace-start, --trace-file, and --trace-ignore
 stayed the same because those only affect the tracing portion of the
 debugging stuff. I never renamed the TraceFlags SCons option to
 DebugFlags.

 So, how do we clear up the confusion? Should I just fix the SCons
 thing and people will just learn? Should I change the name back?
 (There are a ton of places where this would change).

 Anyone care?

 Nate
 ___
 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 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] Review Request: SConstruct: automatically update .hg/hgrc with style hooks

[Ali Saidi]

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

Ship it!


- Ali


On 2011-06-01 21:27:23, Steve Reinhardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/668/
> ---
> 
> (Updated 2011-06-01 21:27:23)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> SConstruct: automatically update .hg/hgrc with style hooks
> 
> Seems easier than pestering people about it.
> Note also that path is now absolute, so you don't get errors
> when invoking hg from subdirectories.
> 
> 
> Diffs
> -
> 
>   SConstruct 3f49ed206f46 
> 
> Diff: http://reviews.m5sim.org/r/668/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steve
> 
>

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

[gem5-dev] changeset in m5: SimObject: allow modules in subclass definitions

[Steve Reinhardt]

changeset aa00cee9abb1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=aa00cee9abb1
description:
SimObject: allow modules in subclass definitions

In particular, this avoids crashing when you do
an import (like "import pdb") inside a SimObject
subclass definition.

diffstat:

 src/python/m5/SimObject.py |  5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diffs (22 lines):

diff -r 681497e0356b -r aa00cee9abb1 src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.pyTue May 31 02:56:22 2011 -0400
+++ b/src/python/m5/SimObject.pyWed Jun 01 21:43:13 2011 -0700
@@ -29,7 +29,7 @@
 #  Nathan Binkert
 
 import sys
-from types import FunctionType, MethodType
+from types import FunctionType, MethodType, ModuleType
 
 try:
 import pydot
@@ -130,7 +130,8 @@
 
 def public_value(key, value):
 return key.startswith('_') or \
-   isinstance(value, (FunctionType, MethodType, classmethod, type))
+   isinstance(value, (FunctionType, MethodType, ModuleType,
+  classmethod, type))
 
 # The metaclass for SimObject.  This class controls how new classes
 # that derive from SimObject are instantiated, and provides inherited
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Debug Flags

[Steve Reinhardt]

OK, now that I'm at a keyboard: if we change the scons thing from
TraceFlag() to DebugFlag(), then there's one set of flags with one set
of names, it's all debug flags.  Some (currently most) of them are
only used to control DPRINTFs, but they could be used for other
things, and the same flag could in theory be used for both DPRINTFs
and other things.

All the --trace-* options solely control things related to DPRINTFs
and/or exec tracing (I believe), so that's consistent too.

It might not be the simplest scheme ever, but it sounds simpler than
having distinct debug flags and trace flags.

Steve

On Wed, Jun 1, 2011 at 8:15 PM, Steve Reinhardt  wrote:
> On my phone, so I'll be brief, but just fixing the scons to be consistent
> sounds good to me.
>
> On Jun 1, 2011 6:55 PM, "Gabriel Michael Black" 
> wrote:
>> So, I think part of the confusion is that there are two names now,
>> debug flags and trace flags, but they're different views of the same
>> mechanism (yes? no?) It seems like the --trace* options are like the
>> --debug* options, except their intended use is a subset of --debug*,
>> specifically DPRINTFs. What about returning the DPRINTF ones to
>> --trace-flags, etc., and introducing a separate parallel set of
>> options and namespace for the debug stuff? There's some macro or
>> something to check if trace flags are turned on, and that encourages
>> their use as debug flags (although I think that use is minimal in the
>> current code). We could introduce a new DEBUG_ON() macro (or a better
>> name) and optionally eliminate the trace oriented one or make it
>> internal to DPRINTFs only. I can think of some valid uses for keeping
>> it like blocks of DPRINTFs like Ali added recently, but it blurs the
>> line and could add to the confusion.
>>
>> By having two parallel systems, even though they're a bit redundant
>> where they overlap, I think it introduces a clear conceptual
>> separation between the two. Then it's clear what trace flags are for
>> and when to use them, and also what debug flags are for and when to
>> use them.
>>
>> We really have two different ideas budding off from each other
>> (controlling tracing and debug features), and by partially bundling
>> them together and partially distinguishing them that leads to
>> confusion. The mental model is different from the way you have to
>> control things, and trying to reconcile the two views makes the system
>> hard to reason about.
>>
>> Gabe
>>
>> Quoting nathan binkert :
>>
>>> Ok, there has been a lot of confusion about debug flags and trace
>>> flags. I changed the way the flags stuff worked from a compile
>>> perspective which required me to make changes throughout the tree, so
>>> I took the opportunity to rename the trace flags to debug flags. The
>>> idea behind the change was that the flags can be used for things other
>>> than tracing (I use them for breakpoints) and there is only one
>>> namespace, so I just renamed it to debug (people did review that
>>> change).
>>>
>>> So, I renamed --trace-flags to --debug-flags and --trace-flags-help to
>>> --debug-flags-help. --trace-start, --trace-file, and --trace-ignore
>>> stayed the same because those only affect the tracing portion of the
>>> debugging stuff. I never renamed the TraceFlags SCons option to
>>> DebugFlags.
>>>
>>> So, how do we clear up the confusion? Should I just fix the SCons
>>> thing and people will just learn? Should I change the name back?
>>> (There are a ton of places where this would change).
>>>
>>> Anyone care?
>>>
>>> Nate
>>> ___
>>> 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 mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request: SConstruct: automatically update .hg/hgrc with style hooks

[Steve Reinhardt]

Reviewboard didn't give me a chance to comment, but this is basically the
same as before except I now prompt for an input before modifying the
.hg/hgrc.  The truly paranoid can hit ctrl-c and get out of there.  I
thought it would be nice to get this in before the tutorial, since ideally
we'll have a bunch of newbies cloning new repositories.

Steve

On Wed, Jun 1, 2011 at 9:27 PM, Steve Reinhardt  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/668/
>   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
> By Steve Reinhardt.
>
> *Updated 2011-06-01 21:27:23.466278*
> Description
>
> SConstruct: automatically update .hg/hgrc with style hooks
>
> Seems easier than pestering people about it.
> Note also that path is now absolute, so you don't get errors
> when invoking hg from subdirectories.
>
>   Diffs (updated)
>
>- SConstruct (3f49ed206f46)
>
> View Diff 
>
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request: SConstruct: automatically update .hg/hgrc with style hooks

[Steve Reinhardt]

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

(Updated 2011-06-01 21:27:23.466278)


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


Summary
---

SConstruct: automatically update .hg/hgrc with style hooks

Seems easier than pestering people about it.
Note also that path is now absolute, so you don't get errors
when invoking hg from subdirectories.


Diffs (updated)
-

  SConstruct 3f49ed206f46 

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


Testing
---


Thanks,

Steve

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

Re: [gem5-dev] Debug Flags

[Steve Reinhardt]

On my phone, so I'll be brief, but just fixing the scons to be consistent
sounds good to me.
On Jun 1, 2011 6:55 PM, "Gabriel Michael Black" 
wrote:
> So, I think part of the confusion is that there are two names now,
> debug flags and trace flags, but they're different views of the same
> mechanism (yes? no?) It seems like the --trace* options are like the
> --debug* options, except their intended use is a subset of --debug*,
> specifically DPRINTFs. What about returning the DPRINTF ones to
> --trace-flags, etc., and introducing a separate parallel set of
> options and namespace for the debug stuff? There's some macro or
> something to check if trace flags are turned on, and that encourages
> their use as debug flags (although I think that use is minimal in the
> current code). We could introduce a new DEBUG_ON() macro (or a better
> name) and optionally eliminate the trace oriented one or make it
> internal to DPRINTFs only. I can think of some valid uses for keeping
> it like blocks of DPRINTFs like Ali added recently, but it blurs the
> line and could add to the confusion.
>
> By having two parallel systems, even though they're a bit redundant
> where they overlap, I think it introduces a clear conceptual
> separation between the two. Then it's clear what trace flags are for
> and when to use them, and also what debug flags are for and when to
> use them.
>
> We really have two different ideas budding off from each other
> (controlling tracing and debug features), and by partially bundling
> them together and partially distinguishing them that leads to
> confusion. The mental model is different from the way you have to
> control things, and trying to reconcile the two views makes the system
> hard to reason about.
>
> Gabe
>
> Quoting nathan binkert :
>
>> Ok, there has been a lot of confusion about debug flags and trace
>> flags. I changed the way the flags stuff worked from a compile
>> perspective which required me to make changes throughout the tree, so
>> I took the opportunity to rename the trace flags to debug flags. The
>> idea behind the change was that the flags can be used for things other
>> than tracing (I use them for breakpoints) and there is only one
>> namespace, so I just renamed it to debug (people did review that
>> change).
>>
>> So, I renamed --trace-flags to --debug-flags and --trace-flags-help to
>> --debug-flags-help. --trace-start, --trace-file, and --trace-ignore
>> stayed the same because those only affect the tracing portion of the
>> debugging stuff. I never renamed the TraceFlags SCons option to
>> DebugFlags.
>>
>> So, how do we clear up the confusion? Should I just fix the SCons
>> thing and people will just learn? Should I change the name back?
>> (There are a ton of places where this would change).
>>
>> Anyone care?
>>
>> Nate
>> ___
>> 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 mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses

[Nilay Vaish]

I had posted a review request, it is not appropriate to respond to it with 
these type of questions. These questions should be asked on gem5-users 
list.


And now the answer to your question. We currently do not update GEMS code. 
And I do not think that there is any plan to do so in future. In fact, we 
advise users to move to gem5.


--
Nilay

On Thu, 2 Jun 2011, huangyongbing wrote:


Hi.

I am currently using GEMS and Simics. So I care about whether the corresponding 
codes are also updated in GEMS.

-Yongbing Huang




发件人： Nilay Vaish
发送时间： 2011-06-02  09:57:40
收件人： Nilay Vaish; Default; Brad Beckmann; Steve Reinhardt; Gabe Black
抄送：
主题： Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/
---
(Updated 2011-06-01 18:59:16.473427)
Review request for Default.
Summary (updated)
---
Ruby: Add support for functional accesses
This patch is meant for implementing functional access support in Ruby.
There is one significant change from the previous version of the patch.
In the previous version, during functional writes, only the cache memories
were being checked. During testing I realized that some of the cache lines
could reside in the TBEs. So, now the check is being done at the controller
level. The controller has to provide a function called getAccessPermission()
for functional accesses to be successful. The default implementation of the
function returns "busy" which means that the functional access cannot
proceed further.
The patch has been tested only for 1 loads and processor count from 1
to 16.
Diffs (updated)
-
 configs/example/ruby_mem_test.py 681497e0356b
 configs/ruby/MESI_CMP_directory.py 681497e0356b
 configs/ruby/MI_example.py 681497e0356b
 configs/ruby/MOESI_CMP_directory.py 681497e0356b
 configs/ruby/MOESI_CMP_token.py 681497e0356b
 configs/ruby/MOESI_hammer.py 681497e0356b
 configs/ruby/Ruby.py 681497e0356b
 src/cpu/testers/memtest/memtest.hh 681497e0356b
 src/cpu/testers/memtest/memtest.cc 681497e0356b
 src/mem/packet.hh 681497e0356b
 src/mem/packet.cc 681497e0356b
 src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b
 src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b
 src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b
 src/mem/protocol/MI_example-cache.sm 681497e0356b
 src/mem/protocol/MI_example-dir.sm 681497e0356b
 src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b
 src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b
 src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b
 src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b
 src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b
 src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b
 src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b
 src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b
 src/mem/ruby/network/Network.cc 681497e0356b
 src/mem/ruby/network/Network.py 681497e0356b
 src/mem/ruby/profiler/Profiler.cc 681497e0356b
 src/mem/ruby/profiler/Profiler.py 681497e0356b
 src/mem/ruby/recorder/Tracer.cc 681497e0356b
 src/mem/ruby/recorder/Tracer.py 681497e0356b
 src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b
 src/mem/ruby/slicc_interface/Controller.py 681497e0356b
 src/mem/ruby/slicc_interface/SConscript 681497e0356b
 src/mem/ruby/system/AbstractMemory.hh PRE-CREATION
 src/mem/ruby/system/AbstractMemory.cc PRE-CREATION
 src/mem/ruby/system/AbstractMemory.py PRE-CREATION
 src/mem/ruby/system/Cache.py 681497e0356b
 src/mem/ruby/system/CacheMemory.hh 681497e0356b
 src/mem/ruby/system/CacheMemory.cc 681497e0356b
 src/mem/ruby/system/DirectoryMemory.hh 681497e0356b
 src/mem/ruby/system/DirectoryMemory.cc 681497e0356b
 src/mem/ruby/system/DirectoryMemory.py 681497e0356b
 src/mem/ruby/system/RubyPort.hh 681497e0356b
 src/mem/ruby/system/RubyPort.cc 681497e0356b
 src/mem/ruby/system/RubySystem.py 681497e0356b
 src/mem/ruby/system/SConscript 681497e0356b
 src/mem/ruby/system/Sequencer.py 681497e0356b
 src/mem/ruby/system/System.hh 681497e0356b
 src/mem/ruby/system/System.cc 681497e0356b
 src/mem/slicc/ast/MemberExprAST.py 681497e0356b
 src/mem/slicc/symbols/Func.py 681497e0356b
 src/mem/slicc/symbols/StateMachine.py 681497e0356b
Diff: http://reviews.m5sim.org/r/611/diff
Testing
---
I have tested functional accesses with the ratio between functional
and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
10:90, 1:99. It is working in all the cases.
Thanks,
Nilay
___
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 mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailm

[gem5-dev] Review Request: SLICC: Add a check function for State Machine

[Nilay Vaish]

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

Review request for Default.


Summary
---

SLICC: Add a check function for State Machine
This patch adds a function for State Machines that will check
whether the provided description in the .sm files includes some
of the required functions, like getState() and setState().


Diffs
-

  src/mem/slicc/ast/MachineAST.py 681497e0356b 
  src/mem/slicc/symbols/StateMachine.py 681497e0356b 

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


Testing
---


Thanks,

Nilay

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

Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses

[huangyongbing]

Hi.

I am currently using GEMS and Simics. So I care about whether the corresponding 
codes are also updated in GEMS.

-Yongbing Huang




发件人： Nilay Vaish 
发送时间： 2011-06-02  09:57:40 
收件人： Nilay Vaish; Default; Brad Beckmann; Steve Reinhardt; Gabe Black 
抄送： 
主题： Re: [gem5-dev] Review Request: Ruby: Add support for functionalaccesses 
 
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/611/
---
(Updated 2011-06-01 18:59:16.473427)
Review request for Default.
Summary (updated)
---
Ruby: Add support for functional accesses
This patch is meant for implementing functional access support in Ruby.
There is one significant change from the previous version of the patch.
In the previous version, during functional writes, only the cache memories
were being checked. During testing I realized that some of the cache lines
could reside in the TBEs. So, now the check is being done at the controller
level. The controller has to provide a function called getAccessPermission()
for functional accesses to be successful. The default implementation of the
function returns "busy" which means that the functional access cannot
proceed further.
The patch has been tested only for 1 loads and processor count from 1
to 16.
Diffs (updated)
-
  configs/example/ruby_mem_test.py 681497e0356b 
  configs/ruby/MESI_CMP_directory.py 681497e0356b 
  configs/ruby/MI_example.py 681497e0356b 
  configs/ruby/MOESI_CMP_directory.py 681497e0356b 
  configs/ruby/MOESI_CMP_token.py 681497e0356b 
  configs/ruby/MOESI_hammer.py 681497e0356b 
  configs/ruby/Ruby.py 681497e0356b 
  src/cpu/testers/memtest/memtest.hh 681497e0356b 
  src/cpu/testers/memtest/memtest.cc 681497e0356b 
  src/mem/packet.hh 681497e0356b 
  src/mem/packet.cc 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b 
  src/mem/protocol/MI_example-cache.sm 681497e0356b 
  src/mem/protocol/MI_example-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b 
  src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b 
  src/mem/ruby/network/Network.cc 681497e0356b 
  src/mem/ruby/network/Network.py 681497e0356b 
  src/mem/ruby/profiler/Profiler.cc 681497e0356b 
  src/mem/ruby/profiler/Profiler.py 681497e0356b 
  src/mem/ruby/recorder/Tracer.cc 681497e0356b 
  src/mem/ruby/recorder/Tracer.py 681497e0356b 
  src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b 
  src/mem/ruby/slicc_interface/Controller.py 681497e0356b 
  src/mem/ruby/slicc_interface/SConscript 681497e0356b 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
  src/mem/ruby/system/Cache.py 681497e0356b 
  src/mem/ruby/system/CacheMemory.hh 681497e0356b 
  src/mem/ruby/system/CacheMemory.cc 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.hh 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.cc 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.py 681497e0356b 
  src/mem/ruby/system/RubyPort.hh 681497e0356b 
  src/mem/ruby/system/RubyPort.cc 681497e0356b 
  src/mem/ruby/system/RubySystem.py 681497e0356b 
  src/mem/ruby/system/SConscript 681497e0356b 
  src/mem/ruby/system/Sequencer.py 681497e0356b 
  src/mem/ruby/system/System.hh 681497e0356b 
  src/mem/ruby/system/System.cc 681497e0356b 
  src/mem/slicc/ast/MemberExprAST.py 681497e0356b 
  src/mem/slicc/symbols/Func.py 681497e0356b 
  src/mem/slicc/symbols/StateMachine.py 681497e0356b 
Diff: http://reviews.m5sim.org/r/611/diff
Testing
---
I have tested functional accesses with the ratio between functional
and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
10:90, 1:99. It is working in all the cases.
Thanks,
Nilay
___
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] Review Request: Ruby: Add support for functional accesses

[Nilay Vaish]

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

(Updated 2011-06-01 18:59:39.117342)


Review request for Default.


Summary
---

Ruby: Add support for functional accesses
This patch is meant for implementing functional access support in Ruby.
There is one significant change from the previous version of the patch.
In the previous version, during functional writes, only the cache memories
were being checked. During testing I realized that some of the cache lines
could reside in the TBEs. So, now the check is being done at the controller
level. The controller has to provide a function called getAccessPermission()
for functional accesses to be successful. The default implementation of the
function returns "busy" which means that the functional access cannot
proceed further.

The patch has been tested only for 1 loads and processor count from 1
to 16.


Diffs
-

  configs/example/ruby_mem_test.py 681497e0356b 
  configs/ruby/MESI_CMP_directory.py 681497e0356b 
  configs/ruby/MI_example.py 681497e0356b 
  configs/ruby/MOESI_CMP_directory.py 681497e0356b 
  configs/ruby/MOESI_CMP_token.py 681497e0356b 
  configs/ruby/MOESI_hammer.py 681497e0356b 
  configs/ruby/Ruby.py 681497e0356b 
  src/cpu/testers/memtest/memtest.hh 681497e0356b 
  src/cpu/testers/memtest/memtest.cc 681497e0356b 
  src/mem/packet.hh 681497e0356b 
  src/mem/packet.cc 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b 
  src/mem/protocol/MI_example-cache.sm 681497e0356b 
  src/mem/protocol/MI_example-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b 
  src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b 
  src/mem/ruby/network/Network.cc 681497e0356b 
  src/mem/ruby/network/Network.py 681497e0356b 
  src/mem/ruby/profiler/Profiler.cc 681497e0356b 
  src/mem/ruby/profiler/Profiler.py 681497e0356b 
  src/mem/ruby/recorder/Tracer.cc 681497e0356b 
  src/mem/ruby/recorder/Tracer.py 681497e0356b 
  src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b 
  src/mem/ruby/slicc_interface/Controller.py 681497e0356b 
  src/mem/ruby/slicc_interface/SConscript 681497e0356b 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
  src/mem/ruby/system/Cache.py 681497e0356b 
  src/mem/ruby/system/CacheMemory.hh 681497e0356b 
  src/mem/ruby/system/CacheMemory.cc 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.hh 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.cc 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.py 681497e0356b 
  src/mem/ruby/system/RubyPort.hh 681497e0356b 
  src/mem/ruby/system/RubyPort.cc 681497e0356b 
  src/mem/ruby/system/RubySystem.py 681497e0356b 
  src/mem/ruby/system/SConscript 681497e0356b 
  src/mem/ruby/system/Sequencer.py 681497e0356b 
  src/mem/ruby/system/System.hh 681497e0356b 
  src/mem/ruby/system/System.cc 681497e0356b 
  src/mem/slicc/ast/MemberExprAST.py 681497e0356b 
  src/mem/slicc/symbols/Func.py 681497e0356b 
  src/mem/slicc/symbols/StateMachine.py 681497e0356b 

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


Testing (updated)
---


Thanks,

Nilay

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

Re: [gem5-dev] Review Request: Ruby: Add support for functional accesses

[Nilay Vaish]

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

(Updated 2011-06-01 18:59:16.473427)


Review request for Default.


Summary (updated)
---

Ruby: Add support for functional accesses
This patch is meant for implementing functional access support in Ruby.
There is one significant change from the previous version of the patch.
In the previous version, during functional writes, only the cache memories
were being checked. During testing I realized that some of the cache lines
could reside in the TBEs. So, now the check is being done at the controller
level. The controller has to provide a function called getAccessPermission()
for functional accesses to be successful. The default implementation of the
function returns "busy" which means that the functional access cannot
proceed further.

The patch has been tested only for 1 loads and processor count from 1
to 16.


Diffs (updated)
-

  configs/example/ruby_mem_test.py 681497e0356b 
  configs/ruby/MESI_CMP_directory.py 681497e0356b 
  configs/ruby/MI_example.py 681497e0356b 
  configs/ruby/MOESI_CMP_directory.py 681497e0356b 
  configs/ruby/MOESI_CMP_token.py 681497e0356b 
  configs/ruby/MOESI_hammer.py 681497e0356b 
  configs/ruby/Ruby.py 681497e0356b 
  src/cpu/testers/memtest/memtest.hh 681497e0356b 
  src/cpu/testers/memtest/memtest.cc 681497e0356b 
  src/mem/packet.hh 681497e0356b 
  src/mem/packet.cc 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-L1cache.sm 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-L2cache.sm 681497e0356b 
  src/mem/protocol/MESI_CMP_directory-dir.sm 681497e0356b 
  src/mem/protocol/MI_example-cache.sm 681497e0356b 
  src/mem/protocol/MI_example-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-L1cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-L2cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_directory-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-L1cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-L2cache.sm 681497e0356b 
  src/mem/protocol/MOESI_CMP_token-dir.sm 681497e0356b 
  src/mem/protocol/MOESI_hammer-cache.sm 681497e0356b 
  src/mem/protocol/MOESI_hammer-dir.sm 681497e0356b 
  src/mem/ruby/network/Network.cc 681497e0356b 
  src/mem/ruby/network/Network.py 681497e0356b 
  src/mem/ruby/profiler/Profiler.cc 681497e0356b 
  src/mem/ruby/profiler/Profiler.py 681497e0356b 
  src/mem/ruby/recorder/Tracer.cc 681497e0356b 
  src/mem/ruby/recorder/Tracer.py 681497e0356b 
  src/mem/ruby/slicc_interface/AbstractController.hh 681497e0356b 
  src/mem/ruby/slicc_interface/Controller.py 681497e0356b 
  src/mem/ruby/slicc_interface/SConscript 681497e0356b 
  src/mem/ruby/system/AbstractMemory.hh PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.cc PRE-CREATION 
  src/mem/ruby/system/AbstractMemory.py PRE-CREATION 
  src/mem/ruby/system/Cache.py 681497e0356b 
  src/mem/ruby/system/CacheMemory.hh 681497e0356b 
  src/mem/ruby/system/CacheMemory.cc 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.hh 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.cc 681497e0356b 
  src/mem/ruby/system/DirectoryMemory.py 681497e0356b 
  src/mem/ruby/system/RubyPort.hh 681497e0356b 
  src/mem/ruby/system/RubyPort.cc 681497e0356b 
  src/mem/ruby/system/RubySystem.py 681497e0356b 
  src/mem/ruby/system/SConscript 681497e0356b 
  src/mem/ruby/system/Sequencer.py 681497e0356b 
  src/mem/ruby/system/System.hh 681497e0356b 
  src/mem/ruby/system/System.cc 681497e0356b 
  src/mem/slicc/ast/MemberExprAST.py 681497e0356b 
  src/mem/slicc/symbols/Func.py 681497e0356b 
  src/mem/slicc/symbols/StateMachine.py 681497e0356b 

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


Testing
---

I have tested functional accesses with the ratio between functional
and timing accesses for different ratios -- 100:0, 99:1, 90:1, 50:50,
10:90, 1:99. It is working in all the cases.


Thanks,

Nilay

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

Re: [gem5-dev] Debug Flags

[Gabriel Michael Black]

So, I think part of the confusion is that there are two names now,  
debug flags and trace flags, but they're different views of the same  
mechanism (yes? no?) It seems like the --trace* options are like the  
--debug* options, except their intended use is a subset of --debug*,  
specifically DPRINTFs. What about returning the DPRINTF ones to  
--trace-flags, etc., and introducing a separate parallel set of  
options and namespace for the debug stuff? There's some macro or  
something to check if trace flags are turned on, and that encourages  
their use as debug flags (although I think that use is minimal in the  
current code). We could introduce a new DEBUG_ON() macro (or a better  
name) and optionally eliminate the trace oriented one or make it  
internal to DPRINTFs only. I can think of some valid uses for keeping  
it like blocks of DPRINTFs like Ali added recently, but it blurs the  
line and could add to the confusion.


By having two parallel systems, even though they're a bit redundant  
where they overlap, I think it introduces a clear conceptual  
separation between the two. Then it's clear what trace flags are for  
and when to use them, and also what debug flags are for and when to  
use them.


We really have two different ideas budding off from each other  
(controlling tracing and debug features), and by partially bundling  
them together and partially distinguishing them that leads to  
confusion. The mental model is different from the way you have to  
control things, and trying to reconcile the two views makes the system  
hard to reason about.


Gabe

Quoting nathan binkert :


Ok, there has been a lot of confusion about debug flags and trace
flags.  I changed the way the flags stuff worked from a compile
perspective which required me to make changes throughout the tree, so
I took the opportunity to rename the trace flags to debug flags.  The
idea behind the change was that the flags can be used for things other
than tracing (I use them for breakpoints) and there is only one
namespace, so I just renamed it to debug (people did review that
change).

So, I renamed --trace-flags to --debug-flags and --trace-flags-help to
--debug-flags-help.  --trace-start, --trace-file, and --trace-ignore
stayed the same because those only affect the tracing portion of the
debugging stuff.  I never renamed the TraceFlags SCons option to
DebugFlags.

So, how do we clear up the confusion?  Should I just fix the SCons
thing and people will just learn?  Should I change the name back?
(There are a ton of places where this would change).

Anyone care?

  Nate
___
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] Debug Flags

[nathan binkert]

Ok, there has been a lot of confusion about debug flags and trace
flags.  I changed the way the flags stuff worked from a compile
perspective which required me to make changes throughout the tree, so
I took the opportunity to rename the trace flags to debug flags.  The
idea behind the change was that the flags can be used for things other
than tracing (I use them for breakpoints) and there is only one
namespace, so I just renamed it to debug (people did review that
change).

So, I renamed --trace-flags to --debug-flags and --trace-flags-help to
--debug-flags-help.  --trace-start, --trace-file, and --trace-ignore
stayed the same because those only affect the tracing portion of the
debugging stuff.  I never renamed the TraceFlags SCons option to
DebugFlags.

So, how do we clear up the confusion?  Should I just fix the SCons
thing and people will just learn?  Should I change the name back?
(There are a ton of places where this would change).

Anyone care?

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

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

[Cron Daemon]

* 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_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-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_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_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 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/00.hello/alpha/linux/simple-timing-ruby-MOESI_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/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-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/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby 
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-timing passed.
* build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/inorder-timing passed.
* build/POWER_SE/tests/opt/quick/00.hello/power/linux/simple-atomic passed.
* build/POWER_SE/tests/opt/quick/00.hello/power/linux/o3-timing passed.
* build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing 
passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp
 passed.
* 
build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
 passed.
* build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed.
* build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing passed.
* build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic passed.
* build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing passed.
* build/X86_SE/tests/opt/quick/00.hello/x86/linux/simple-atomic passed.
* 
build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* build/X86_SE/tests/opt/quick/0