---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/#review727
---
I can't fully appreciate these latest changes without also seeing the
On 2011-01-13 08:33:49, Brad Beckmann wrote:
I can't fully appreciate these latest changes without also seeing the
updated .sm files, but overall this looks very inline with what we have
been discussing over the past few days. I just have one basic question on
why we need to
On 2011-01-13 08:33:49, Brad Beckmann wrote:
I can't fully appreciate these latest changes without also seeing the
updated .sm files, but overall this looks very inline with what we have
been discussing over the past few days. I just have one basic question on
why we need to
On Tue, January 11, 2011 7:24 pm, Lisa Hsu wrote:
Hi Nilay,
I've been talking with Brad here at work about some of these things so I
will finally jump into the conversation via email. First, great job on
this
- this has clearly been a substantial amount of work. I'm impressed.
I've got
Hi Brad,
As I understand from your mail below, you do would like to write
ENTRY L1I_cache_entry = getL1ICacheEntry(in_msg.LineAddress);
trigger(Event, address, L1I_cache_entry);
instead of
set_cache_entry(getL1ICacheEntry(in_msg.LineAddress));
trigger(Event, address);
In other words, local
Are you sure you would call the above piece of code as __implicit__ setting
of cache and tbe entry variables? In this case, the local variable has been
__explicitly__ passed in the call to the trigger function.
To me 'X is implicit' means that the programmer does not need to write 'X'
in
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2011-01-12 22:37:49.117675)
Review request for Default.
Summary
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2011-01-12 22:42:07.876214)
Review request for Default.
Summary
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2011-01-12 22:45:22.150420)
Review request for Default.
Summary
---
Hi Nilay,
Sure, using a local variable to further reduce the calls to getCacheEntry is a
great idea. I think that is orthogonal to the suggestion I was making. I just
want the ability to directly set the cache_entry and tbe_entry variables in the
trigger function. That way the address,
On Tue, 11 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and tbe_entry variables in the
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and tbe_entry variables in the trigger function. That way
the address,
Brad, my comments are inline.
On Tue, 11 Jan 2011, Beckmann, Brad wrote:
Sure, using a local variable to further reduce the calls to
getCacheEntry is a great idea. I think that is orthogonal to the
suggestion I was making. I just want the ability to directly set the
cache_entry and
Hi Nilay,
Overall, I believe we are in more agreement with each other than maybe you
think. I'm glad you included pseudo code in your latest email. That is a
great idea. I think part of our problem is we are comprehending our textual
descriptions in different ways.
Below are my responses:
Hi Nilay,
I've been talking with Brad here at work about some of these things so I
will finally jump into the conversation via email. First, great job on this
- this has clearly been a substantial amount of work. I'm impressed.
I've got some comments below.
On Tue, Jan 11, 2011 at 3:46 PM,
Hi Nilay,
Unfortunately I can't provide you an example of a protocol where getCacheEntry
behaves in a different manner, but they do exist. I reviewed your most recent
patch updates and I don't think what we're asking for is much different than
what you have on reviewboard right now.
Brad, my comments are inline.
On Fri, 7 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
Unfortunately I can't provide you an example of a protocol where
getCacheEntry behaves in a different manner, but they do exist. I
reviewed your most recent patch updates and I don't think what we're
Can you give me an example of a protocol where getCacheEntry() behaves in
a different manner?
--
Nilay
On Wed, 5 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
Lisa Hsu (another member of the lab here at AMD) and I were discussing
these changes a bit more and there was one particular idea that
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2011-01-06 07:29:17.470364)
Review request for Default.
Changes
---
Hi Nilay,
Lisa Hsu (another member of the lab here at AMD) and I were discussing these
changes a bit more and there was one particular idea that came out of our
conversation that I wanted to relay to you. Basically, we were thinking about
how these changes will impact the flexibility of SLICC
On 2011-01-03 15:31:20, Brad Beckmann wrote:
Hi Nilay,
First, I must say this is an impressive amount of work. You definitely got a
lot done over holiday break. :)
Overall, this set of patches is definitely close, but I want to see if we can
take them a step forward. Also I have a few
Hi Nilay,
On deadlock issue with MESI_CMP_directory :
Yes, this can happen as ruby_tester or Sequencer only reports
*possible* deadlocks. With higher number of processors there is more
contention (and thus latency) and it can mistakenly report deadlock. I
generally look at the protocol
Hi Nilay,
My responses are below:
The main thing I would like to see improved is not having to differentiate
between “entry†and “entry_ptr†in the .sm files. Am I correct
that the only functions in the .sm files that are passed an
“entry_ptr†are “is_valid_ptrâ€,
Brad
Is there a reason why each action name follows the pattern combination of
several letters_action performed by the action? The letters used are
not abbreviations of the action performed. Can we use any combination?
Thanks
Nilay
On Tue, 4 Jan 2011, Beckmann, Brad wrote:
Hi Nilay,
My
Hi Nilay,
At one point in time, the combination of several letters at the beginning of
the action name corresponded to the short hand name for the action. The short
hand name is the letter or letter combination that appears in the HTML tables.
SLICC may have once enforced that the
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/#review585
---
src/mem/ruby/slicc_interface/AbstractCacheEntry.hh
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2011-01-03 14:18:13.801375)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/#review596
---
Hi Nilay,
First, I must say this is an impressive amount of work. You
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2010-12-31 17:50:59.779517)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
(Updated 2010-12-24 09:04:02.816498)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/
---
Review request for Default.
Summary
---
The purpose of this patch is to
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/#review570
---
Hi Nilay,
Could you please include the changes to the
On 2010-12-22 14:35:28, Brad Beckmann wrote:
Hi Nilay,
Could you please include the changes to the MOESI_CMP_directory protocol in
this patch? It is difficult to understand the ramifications of these changes
without seeing their impact to the .sm files. Also this is a very tricky patch
33 matches
Mail list logo
