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
---
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 Bl
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 wrote:
> 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 ne
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, 2011
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
On Fri, Jan 21, 2011 at 11:33 AM, nathan binkert 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). [...]
>
Agre
> 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).
> 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
Not saying you have to do it this way; a smaller change that universally
improves on the status quo and makes it work for your situation is fine with
me...
On Fri, Jan 21, 2011 at 11:21 AM, Steve Reinhardt wrote:
> I was thinking about this a little more, and I think if we really want to
> get i
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 most
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
don'
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
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 != s
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
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 thro
---
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
Binke
Agreed.
On Wed, Jan 19, 2011 at 1:50 PM, Ali Saidi 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
> wrote:
>
>> I don't think anyone would have any probl
> 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 clas
> 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 t
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 Ru
On Thu, 20 Jan 2011, nathan binkert wrote:
So how would you handle pointer to an object which is reference counted?
Pointer to the same object may be being used at multiple places.
That's what the RefCountingPtr class is all about. It is a "smart
pointer" and automatically increments and decr
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 Th
---
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
---
> 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 t
---
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
---
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
scons: *** Source
`tests/quick/60.rubytest/ref/alpha/linux/rubytest-ruby-MOESI_CMP_directory/stats.txt'
not found, needed by target
`build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory/status'.
*
build/ALPHA_SE_MOESI_hammer/tests/fas
27 matches
Mail list logo