---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/326/
---
Review request for Default.
Summary
---
This request for reviewing the updates
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/335/
---
(Updated 2010-12-31 17:28:19.882643)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/280/
---
(Updated 2010-12-31 17:26:11.666038)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/280/
---
Review request for Default.
Summary
---
This request is for reviewing the upda
On Thu, 30 Dec 2010, nathan binkert wrote:
I was looking at the implementation of floorLog2() in src/base/intmath.hh. I
think this implementation is not the best that can be done. We should use a
GCC builtin __builtin_clz* to implement these functions. I have not carried
out any test to get t
I was looking at the implementation of floorLog2() in src/base/intmath.hh.
I think this implementation is not the best that can be done. We should
use a GCC builtin __builtin_clz* to implement these functions. I have not
carried out any test to get the execution times for two different
implemen
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/361/
---
Review request for Default.
Summary
---
This patch adds an option to the scrip
---
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/359/
---
(Updated 2010-12-24 09:02:20.653744)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/335/
---
Review request for Default.
Summary
---
This is a review request for the patch
ent from my ARM powered device
On Dec 23, 2010, at 1:10 PM, Nilay Vaish wrote:
I am able to reproduce the warning. But I have to compile the files on
my own (as in, write the compilation command on the command line) in
order to reproduce the warning.
This is the proposed patch.
--
Nilay
d
changeset. As a stop gap, I guess this is OK, but this really is not
the right fix.
Nate
On Thu, Dec 23, 2010 at 11:41 AM, Nilay Vaish wrote:
changeset fbf4b1b18202 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fbf4b1b18202
description:
PerfectCacheMemory: Add re
changeset fbf4b1b18202 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fbf4b1b18202
description:
PerfectCacheMemory: Add return statements to two functions.
Two functions in src/mem/ruby/system/PerfectCacheMemory.hh,
tryCacheAccess()
and cacheProbe(), end
e if an address is present in the cache
@@ -167,6 +168,7 @@
PerfectCacheMemory::cacheProbe(const Address& newAddress) const
{
panic("cacheProbe called in perfect cache");
+return newAddress;
}
// looks an address up in the cache
On Thu, 23 Dec 2010, Nilay Vaish wrote
t works for you. That's just speculation on my part though.
Does anyone else have any experience with this? Does the error go away on
4.2.4 if you put the dead 'return' statement back in the particular place
that it's complaining about?
Steve
On Thu, Dec 23, 2010 at 8:12 AM, N
Steve, you had commented that panic() and fatal() are marked as "no
return". Then, why should these warnings appear? And why would the
compiler be fine with ERROR_MSG?
--
Nilay
On Thu, 23 Dec 2010, Nilay Vaish wrote:
I am using GCC 4.4, I never see any of these warnings. Let m
you're not seeing that with any of the builds, maybe you're using a
different gcc version... zizzer has 4.2.4.
Or maybe something's just messed up on zizzer... let me know if you think
those errors are bogus.
Steve
On Thu, Dec 23, 2010 at 7:36 AM, Nilay Vaish wrote:
I ran the regr
orget to compile m5.fast. Things are compiled differently in
m5.debug/m5.opt and m5.fast
Nate
On Thu, Dec 23, 2010 at 6:52 AM, Nilay Vaish wrote:
I am looking in to why the tests failed.
--
Nilay
On Thu, 23 Dec 2010, Cron Daemon wrote:
scons: ***
[build/ALPHA_SE_MOESI_CMP_directory/mem/pro
I am looking in to why the tests failed.
--
Nilay
On Thu, 23 Dec 2010, Cron Daemon wrote:
scons: ***
[build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_changePermission.fo]
Error 1
scons: ***
[build/ALPHA_SE_MOESI_CMP_directory/mem/protocol/L2Cache_Controller.fo] Error 1
scons: ***
[
changeset f249937228b5 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f249937228b5
description:
This patch removes the WARN_* and ERROR_* from
src/mem/ruby/common/Debug.hh file. These statements have been replaced with
warn(), panic() and fatal() defined in src/base/mi
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/359/
---
Review request for Default.
Summary
---
This is a request for reviewing the pr
w all the changes.
--
Nilay
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/358/#review570
---
On 2010-12-22 14:21:09, Nilay Va
---
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 change
4:31 a.m., Nilay Vaish wrote:
Review request for Default.
By Nilay Vaish.
*Updated 2010-12-21 04:31:14*
Description
This patch removes the WARN_* and ERROR_* from src/mem/ruby/common/Debug.hh
file. These statements have been replaced with warn(), panic() and fatal()
defined in src/base/mi
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/336/
---
(Updated 2010-12-21 19:43:15.419690)
Review request for Default.
Changes
---
m.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Nilay Vaish
Sent: Tuesday, December 21, 2010 1:04 PM
To: m5-dev@m5sim.org
Subject: [m5-dev] Deadlock while running ruby_random_test.py
I am running ALPHA_SE_MESI_CMP_directory with ruby_random_test.py. I supply the
option -l as 2000. I have paste
I am running ALPHA_SE_MESI_CMP_directory with ruby_random_test.py. I
supply the option -l as 2000. I have pasted the output below. This was
generated using latest version of m5.
Actually, while testing my own changes to SLICC and protocol files, I
also observe the dead lock at the 301. So
How do you make reviewboard accept two review requests A and B where both
A and B make changes to some common files?
--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/336/
---
(Updated 2010-12-21 04:31:14.033111)
Review request for Default.
Changes
---
the tester then that's not so bad, but if you're running a regular
program that seems high.
Thanks,
Steve
On Mon, Dec 20, 2010 at 9:47 AM, Nilay Vaish wrote:
These profile results from testing ALPHA_FS_MESI_CMP_directory with
configs/example/ruby_fs.py. The simulation was allowed to run
running a regular
program that seems high.
Thanks,
Steve
On Mon, Dec 20, 2010 at 9:47 AM, Nilay Vaish wrote:
These profile results from testing ALPHA_FS_MESI_CMP_directory with
configs/example/ruby_fs.py. The simulation was allowed to run for
200,000,000,000 ticks.
Profile Res
These profile results from testing ALPHA_FS_MESI_CMP_directory with
configs/example/ruby_fs.py. The simulation was allowed to run for
200,000,000,000 ticks.
Profile Result with unmodified SLICC
% cumulative self self total
time seconds secondscalls s/call s/
Brad
I have tested the changes that I made to files relating to SLICC and
MESI_CMP_directory protocol. I see a 90% decrease in the number of calls
to isTagPresent() when I run m5.prof for 200,000,000,000 ticks using
configs/examples/ruby_fs.py.
Thanks
Nilay
On Fri, 17 Dec 2010, Nilay
this diff?
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/336/#review540
---
On 2010-12-19 12:02:55, Nilay Vaish wrote:
>
> --
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/336/
---
(Updated 2010-12-19 12:02:55.605887)
Review request for Default.
Changes
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/336/
---
(Updated 2010-12-17 17:38:11.53)
Review request for Default.
Summary (updated
Brad, in case you want to have look at the changes that I made so far,
I have attached the patch with this mail.
On Sun, 12 Dec 2010, Nilay Vaish wrote:
Hi Brad,
I have added implicit variables for TBE and Cache entry pointers. These get
inserted in to the doTransition() calls made in
can be used in side the function.
Thanks
Nilay
On Sat, 11 Dec 2010, Nilay Vaish wrote:
Brad
We would need to change the lookup functions for TBETable and CacheMemory.
Currently the lookup functions assume that the address passed on to the
lookup is present. This requires two lookups to the
Brad
We would need to change the lookup functions for TBETable and CacheMemory.
Currently the lookup functions assume that the address passed on to the
lookup is present. This requires two lookups to the data structures
associated with these classes, one for checking whether the address is in
It works perfectly. Thanks!
Nilay
On Thu, 9 Dec 2010, Beckmann, Brad wrote:
Hi Nilay,
Yes, I believe a machine can be accessed within AST class functions, though I
don't remember ever doing it myself. Look at the generate() function in
TypeFieldEnumAST. Here you see that the machine (a.k.
definitely a portion I feel can be pushed to the
end or removed entirely.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Nilay Vaish
Sent: Wednesday, December 08, 2010 11:53 AM
To: M5 Developer List
Subject: Re: [m5-dev] Implemen
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/336/
---
Review request for Default.
Summary
---
This patch removes the WARN_* and ERRO
Thanks Brad.
On Wed, 8 Dec 2010, Beckmann, Brad wrote:
Done.
Brad
-Original Message-
From: Nilay Vaish [mailto:ni...@cs.wisc.edu]
Sent: Tuesday, December 07, 2010 4:43 PM
To: Beckmann, Brad
Cc: Default
Subject: Re: Review Request: NDEBUG for Ruby Assert statement
Brad,
Since
s lines of SLICC code. I hope that these changes are straight forward, but
any change like that is never really "straight forward".
Let's think it over some more and let me know if you want to discuss this in
more detail over-the-phone.
Brad
-----Original Message-
From: m5
about this over a phone conversation.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Nilay Vaish
Sent: Tuesday, December 07, 2010 12:16 AM
To: M5 Developer List
Subject: Re: [m5-dev] Implementation of findTagInSet
I have made change
://reviews.m5sim.org/r/337/#review509
---
Ship it!
Looks good to me.
- Brad
On 2010-12-02 20:35:31, Nilay Vaish wrote:
---
This is an automatically generated e-mail. To reply, visit
I have made changes to SLICC to support local reference variables. I think
we should reference variables in functions where back to back calls are
made to lookup/getCacheEntry functions.
Overall, I am still unclear how can we handle this issue.
Nilay
On Tue, 30 Nov 2010, Nilay Vaish wrote
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/337/#review510
---
On 2010-12-02 20:35:31, Nilay Vaish wrote:
>
> ---
has a valid state, then it is used. Else the state of the cache entry is
looked and used if valid.
Nilay
On Tue, 30 Nov 2010, Nilay Vaish wrote:
Is it possible to have variables local to a function in .sm files. I am
thinking of storing getCacheEntry()'s return value in a local var
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/337/
---
(Updated 2010-12-02 20:35:31.660861)
Review request for Default.
Summary
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/337/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
Binke
/re.py", line 245, in _compile
raise error, v # invalid expression
error: nothing to repeat
On Thu, 2 Dec 2010 13:09:45 -0600 (CST), Nilay Vaish
wrote:
I click on the New Review Request button. Then, I click the browse
button to supply the path of the diff file. After that when I pr
everything we're doing that works just fine?
Ali
On Thu, 2 Dec 2010 06:06:28 -0600 (CST), Nilay Vaish
wrote:
I tried again, but I still receive the same error.
Nilay
On Wed, 1 Dec 2010, Ali Saidi wrote:
You might have just hit some issue. Try again.
Ali
On Dec 1, 2010, at 6:10 PM,
I tried again, but I still receive the same error.
Nilay
On Wed, 1 Dec 2010, Ali Saidi wrote:
You might have just hit some issue. Try again.
Ali
On Dec 1, 2010, at 6:10 PM, Nilay Vaish wrote:
Ali had updated the review board some time back. May be something was not
correctly configured
squashed.
Gabe
Nilay Vaish wrote:
I was trying to create a new review request. On pressing the 'Create
Review Request' button, I receive the following error.
Something broke! (Error 500)
It appears something broke when you tried to go to here. This is
either a bug in Review Board or a s
I was trying to create a new review request. On pressing the 'Create
Review Request' button, I receive the following error.
Something broke! (Error 500)
It appears something broke when you tried to go to here. This is either a
bug in Review Board or a server configuration error. Please report
changeset 42da07116e12 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=42da07116e12
description:
ruby: Converted old ruby debug calls to M5 debug calls
This patch developed by Nilay Vaish converts all the old GEMS-style ruby
debug calls to the
acements are handled.
I have a few other things I need to take care of first, but I may be
able to look into the details of how to make this work by the end of the
week.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of
Nilay
Is it not possible to redesign the functions to accept CacheEntry as a
paramemter instead of a Address parameter?
On Sat, 27 Nov 2010, Nilay Vaish wrote:
I conducted an experiment to figure out how many calls are made to the hash
table to check if the given address exists in the cache. For
to remove the const labels from any of the function calls.
Steve
On Fri, Nov 26, 2010 at 9:37 AM, Nilay Vaish wrote:
I profiled the un-modified and the modified m5 ten times (this time there
was no load on the machine). Here are the average results:
% time std. dev actual time
rmissions(Index cacheSet,
const Address& tag) const;
@@ -170,6 +170,10 @@
int m_cache_num_set_bits;
int m_cache_assoc;
int m_start_index_bit;
+
+Address m_mru_address;
+int m_mru_tag_index;
+ bool m_valid_mru_address;
};
#endif //
Tue, 23 Nov 2010, Nilay Vaish wrote:
Brad and I will be having a discussion today on how to resolve this issue.
--
Nilay
On Tue, 23 Nov 2010, Steve Reinhardt wrote:
Thanks for tracking that down; that confirms my suspicions.
I think the long-term answer is that the system needs to be rewor
ore resorting to the hash table. I hope that
doesn't lead to any coherence problems with the block changing out from
under this cached copy... if so, perhaps an additional block check is
required on hits.
Steve
On Tue, Nov 16, 2010 at 3:17 PM, Nilay Vaish wrote:
I was looking at th
ue or false), getCacheEntry(address) is called. Surprisingly, the
getCacheEntry() function calls the isTagPresent() function again. These
calls are in the file src/mem/protocol/MOESI_hammer-cache.sm
Thanks
Nilay
On Tue, 16 Nov 2010, Nilay Vaish wrote:
I profiled M5 using MOESI_CMP_director
On Fri, 12 Nov 2010, Steve Reinhardt wrote:
Right now I am profiling with coherence protocol as MOESI_hammer. I am
thinking of profiling using a different protocol to make sure that it is not
an artifact of the protocol in use.
That sounds like a good idea.
All in all, we would ideally li
.
In order to reduce the number of calls made to tag lookup, I would need to
read about the protocol itself. Can you point some documentation on
MOESI_hammer protocol?
--
Nilay
On Fri, 12 Nov 2010, Steve Reinhardt wrote:
On Fri, Nov 12, 2010 at 1:10 PM, Nilay Vaish wrote:
I tried couple
h the tags).
If we reorder the tags to search the MRU block first then we will
probabilistically keep the average number of tags searched well below N.
Steve
On Fri, Nov 5, 2010 at 9:27 AM, Nilay Vaish wrote:
I had another look at the profile output. On the machine that I am using (a
3.2 GHz Pe
I went through the implementation of hash_map in C++. I realized that the
number of buckets get resized on the fly as the number of elements
increase. This means that we would have more than num_of_cache_sets *
num_ways buckets in the hash table.
--
Nilay
On Sat, 6 Nov 2010, Nilay Vaish
N is small (a shift and an
add to find the tag index, at most N loads and compares to match the tags).
If we reorder the tags to search the MRU block first then we will
probabilistically keep the average number of tags searched well below N.
Steve
On Fri, Nov 5, 2010 at 9:27 AM, Nilay Vaish wrote
On Fri, 5 Nov 2010, Nilay Vaish wrote:
Do you know what hash function is in use? Seems to me that the default hash
function is to hash to self. May be we should test with a different hash
function.
--
Nilay
On Fri, 5 Nov 2010, Steve Reinhardt wrote:
You can look at the call graph profile
figure out how much time is spent in functions that get called from
isTagPresent. If it's not specifically calling out findTagInSet, it may be
because it's inlined in isTagPresent.
Steve
On Fri, Nov 5, 2010 at 7:58 AM, Nilay Vaish wrote:
I ran ALPHA_FS_MOESI_hammer using the followi
I ran ALPHA_FS_MOESI_hammer using the following command --
./build/ALPHA_FS_MOESI_hammer/m5.prof ./configs/example/ruby_fs.py
I don't know how the benchmark is picked in case none is specified. Below
is the gprof output --
% cumulative self self total
time seconds
I tried running ruby_fs.py, below is the error message that I received. I
don't think there is any documentation or mailing list discussion on how
to run ruby_fs.py. To me it seems that some parameter relating to the DMA
controller is missing from the command I tried out.
--
Nilay
./build/AL
doesn't matter a lot).
If you've never used gprof before, this is a great time to learn!
Steve
On Tue, Nov 2, 2010 at 10:40 AM, Nilay Vaish wrote:
I am looking at possible performance optimizations in Ruby. As you can see
grasp from the mail excerpt below, the function findTagInSet
did you arrive at the conclusion that findTagInSet() is a problem? What
benchmarks, profiling tools to use?
Thanks
Nilay
-- Forwarded message --
Date: Mon, 20 Sep 2010 22:57:39 -0500
From: "Beckmann, Brad"
To: 'Nilay Vaish'
Cc: Daniel Gibson
Sub
Nate, the idea behind this set of changes is to do away with the debug
support (including DEBUG_EXPR) provided by Ruby. Deciding whether given
volume of debug output is too verbose or not will vary from situation to
situation. Since M5 does not have a verbosity level, it is better not to
have i
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/
---
(Updated 2010-10-26 10:17:01.760756)
Review request for Default and Ruby Reviewers.
I have a general question. How do you maintain multiple uncommitted
patches? Suppose you are working on two or more different features /
changes that would be committed separately. How do you maintain these
different changes till they are committed (sounds like a transaction)? Do
you make a cop
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/
---
(Updated 2010-10-25 13:10:22.143949)
Review request for Default and Ruby Reviewers.
prefer
having separate trace flags for these two.
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review415
-------
On 2010-10-25 07:54:18, Nilay Vaish wrote:
>
> --
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/
---
(Updated 2010-10-25 07:54:18.182412)
Review request for Default and Ruby Reviewers.
make these calls a lot less
> > verbose.
I will make these changes and update the diff soon.
- Nilay
-------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review415
--
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/
---
(Updated 2010-10-24 08:59:56.664764)
Review request for Default and Ruby Reviewers.
e
> > flag as the first arg, and "%str" probably isn't the format string you want
> > (basically it's just like printf, so you probably mean "%s").
>
> Nilay Vaish wrote:
> The DPRINTF statements that appear in .sm files are re-written by
would be the format specifier for printing an
object of some class that supports << operator?
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review398
---
On 2010-1
le name, line number from Ruby DPRINTF
statements.
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review399
---
On 2010-10-19 17:30:
ay not be the right person to make
that decision.
- Nilay
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review398
---
On 2010-10-19
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/
---
(Updated 2010-10-19 17:30:48.985205)
Review request for Default and Ruby Reviewers.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/
---
Review request for Ruby Reviewers.
Summary
---
Ruby currently uses GEMS debug
tead.
- Consolidate under a single stats infrastructure and stats output file.
...Of course there is the Bochs work as well, but that isn't necessarily Ruby
related.
Others, please feel free to add to the list.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-de
What's next on the TODO list for Ruby?
--
Nilay
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/21/#review44
---
Ship it!
- Nilay
On 2010-06-02 15:56:26, Nathan Binkert wrote:
>
> -
> On 2010-06-07 20:11:13, Nilay Vaish wrote:
> > 1. Should we use resize() or should we use reserve() for setting the
> > capacity of a vector? Especially during initialization, reserve() might be
> > faster since it does not initialize the allocated memory where as resi
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/24/#review43
---
Ship it!
Looks good.
- Nilay
On 2010-06-02 15:56:55, Nathan Binkert wrot
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/23/#review42
---
Ship it!
Looks fine to me.
- Nilay
On 2010-06-02 15:56:45, Nathan Binker
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/23/#review41
---
Ship it!
Looks fine to me.
- Nilay
On 2010-06-02 15:56:45, Nathan Binker
> On 2010-06-07 20:11:13, Nilay Vaish wrote:
> > 1. Should we use resize() or should we use reserve() for setting the
> > capacity of a vector? Especially during initialization, reserve() might be
> > faster since it does not initialize the allocated memory where as resi
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/22/#review38
---
Ship it!
1. Should we use resize() or should we use reserve() for setting t
> On 2010-06-06 12:34:28, Nilay Vaish wrote:
> > The changes seem
> >
> > I have two observations
> >
> > 1. In several places we are using dynamic_cast. The patch under
> > consideration moves some of these to safe_cast and retains dynamic_cast
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/21/#review35
---
The changes seem
I have two observations
1. In several places we are usin
301 - 400 of 401 matches
Mail list logo
