I get the feeling you are asking about using the same RefCountingPtr
instance in multiple places: don't do that. It will only complicate
matters.
Just copy the RefCountingPtr, like you would copy a standard pointer.
The copy constructor and destructor in RefCountingPtr will make sure
it's handled
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/327/
---
(Updated 2011-01-21 05:03:54.622452)
Review request for Default.
Summary
---
On 2011-01-20 15:49:13, Brad Beckmann wrote:
I've only had a chance to briefly review this, but I do have a couple
comments:
- The hammer cache changes didn't seem to upload cleanly. Can you try to post
them again?
- I just want to confirm that the libruby interface is still useful to
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/327/
---
(Updated 2011-01-21 05:19:07.165598)
Review request for Default.
Summary
---
Indeed it helped.
Thanks
Nilay
On Thu, 20 Jan 2011, Joel Hestness wrote:
Hi Nilay,
I believe that this error is fixed in one of the patches that I worked on
while at AMD. Brad has pushed it up for review:
http://reviews.m5sim.org/r/381/. It's a one line fix.
Hope this helps,
Joel
On
No, my idea was not to share the same RefCountingPtr. I was trying to
share the pointer to an object reference to which are being counted. If
you take a look at the patches that I have posted on the m5 review board,
I am trying to use the same RubyRequest object in multiple places. The
class
On 2011-01-20 15:49:13, Brad Beckmann wrote:
I've only had a chance to briefly review this, but I do have a couple
comments:
- The hammer cache changes didn't seem to upload cleanly. Can you try to post
them again?
- I just want to confirm that the libruby interface is still useful to
Agreed.
On Wed, Jan 19, 2011 at 1:50 PM, Ali Saidi sa...@umich.edu wrote:
I would not complain if the build times went up slightly but I didn't need
8GB of RAM to do a -j 6 build. ;)
Ali
On Wed, 19 Jan 2011 09:02:13 -0800, nathan binkert n...@binkert.org
wrote:
I don't think anyone
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/436/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
I think the purpose of libruby was that back in the day GEMS/Ruby was able
to be hooked up to several other drivers like Bochs, and libruby
encapsulated the APIs to be able to talk to these other guys.
Caveat - this is what I recall hearing Brad say, I can't say for sure. But
since I'm going
I like this idea a lot. Not only would it solve the SERIALIZE_* v. paramOut
usage problem, but it would also decouple the code variable name from the
name written to the checkpoint. If used intelligently, this could alleviate
some of the pain of fixing old checkpoints when code changes.
Joel
Hi,
How can I enforce the reordering restriction between stores in the O3 (W-W
restriction)? To make an store to be executed only after all stores issued
before it were executed.
I tried adding this condition in the executeStore method in
lsq_unit_impl.hh, but it didn't work:
if (store_idx !=
I agree with your point about dup. I imagine we can keep an additional field
that determines whether a file descriptor was created by dup and if so,
re-open it with dup at the point of checkpoint restore. I will work on a fix
and post the diff.
Best,
-Rick
On Thu, Jan 20, 2011 at 10:32 PM, Steve
My initial reaction to Gabe's email is that I'd rather go the other way, and
make SERIALIZE_SCALAR() look more like paramOut() than the other way around.
I don't generally like preprocessor macros, but in this case the
convenience of not having to type the variable name twice justified it. I
I sympathize with Joel's point about compatibility, but 90% of the vars have
the same name in the checkpoint and I don't want the redundancy of saying
things twice. I think the answer there is not to change the infrastructure
but just to be more sensitive in the review process and not just
I was thinking about this a little more, and I think if we really want to
get it right we need a more comprehensive change that better mirrors what's
going on inside the OS, where dup'd fds are really just different pointers
to the same underlying file object (including the file pointer). So
On Fri, Jan 21, 2011 at 11:33 AM, nathan binkert n...@binkert.org wrote:
We had discussed changing serialization so that there was a serializer
class and paramOut/paramIn were methods of that class (getting rid of
the os parameter for ParamOut and the cp and section parameters of
param in).
I have changed the wiki to say that we recommend using the development
repository (over m5-stable), since in practice that really is better.
Lisa
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
In general, the algorithm should probably be:
- pick one and try it... if it works for you, great.
- if not, try the other one
- if neither one works, ask on m5-users
If people followed this approach, then it wouldn't matter nearly as much
which one they started with.
Steve
On Fri, Jan 21,
I'm on a roll with overhead stuff at work today. Updated again to reflect
the sentiment below.
On Fri, Jan 21, 2011 at 3:09 PM, Steve Reinhardt ste...@gmail.com wrote:
In general, the algorithm should probably be:
- pick one and try it... if it works for you, great.
- if not, try the other
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/380/
---
(Updated 2011-01-21 16:39:38.310375)
Review request for Default, Ali Saidi, Gabe
changeset d38c1f650a4e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d38c1f650a4e
description:
SConstruct: Fix the librt check in SConstruct.
diffstat:
SConstruct | 7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diffs (17 lines):
diff -r 494b5426e70d
22 matches
Mail list logo
