scons: *** Implicit dependency `build/ALPHA_SE/params/RubyDebug.hh' not found,
needed by target `build/ALPHA_SE/python/m5/internal/param_RubySystem_wrap.cc'.
scons: *** Implicit dependency
`build/ALPHA_SE_MOESI_hammer/params/RubyDebug.hh' not found, needed by target
I initially thought this was your RubyDebug.hh change, Nate, but I don't
see RubyDebug in the repository anywhere now. In the past I've run into
problems where left over files make a build break until you wipe it out
and rebuild, specifically having to do with the python stuff. I suspect
if you
I also received this error after I pulled in Nate's changeset. Removing
the build directory fixed the problem for me.
Nilay
On Tue, January 11, 2011 4:35 am, Gabe Black wrote:
I initially thought this was your RubyDebug.hh change, Nate, but I don't
see RubyDebug in the repository anywhere now.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/396/
---
(Updated 2011-01-11 08:14:04.743657)
Review request for Default, Ali Saidi, Gabe
I also received this error after I pulled in Nate's changeset. Removing
the build directory fixed the problem for me.
That rings a bell. I think it happened, but I'm not sure why that
happened. I'll blow away the build directory on zizzer.
Nate
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/399/
---
(Updated 2011-01-11 09:27:55.596573)
Review request for Default, Ali Saidi, Gabe
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/420/#review721
---
After you delete the commented out lines, please check it in. I was
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,
I'd advise against putting the comments in two places since they
probably wouldn't stay in sync/up to date. You could refer from one
comment to the other, though, and have it in two places through indirection.
Gabe
On 01/10/11 16:45, Ali Saidi wrote:
This is an automatically generated e-mail.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/399/#review722
---
Ship it!
- Steve
On 2011-01-11 09:27:55, Brad Beckmann wrote:
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
I just had this break a few checkpoints myself - and it's not a big deal
really because it's easily fixup-able...but I wonder whether you really want
to serialize the size of the physmem - let's say you run a checkpointing run
with physmem N gigs and then you restore with physmem M gigs...I don't
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,
I haven't followed this thread closely, but I don't understand this response.
Nate
Yes, because if you're mmapping a file, it's likely that the file is
slightly smaller than the size of memory allocated.
Ali
On Jan 11, 2011, at 5:50 PM, Lisa Hsu wrote:
I just had this break a few
Hello, everyone,
In the m5-dev version, I was trying to build ALPHA_FS_MOESI_CMP_directory
by just changing the ALPHA_SE_MOESI_CMP_directory to the following script.
FULL_SYSTEM = 1
SS_COMPATIBLE_FP = 1
CPU_MODELS = 'AtomicSimpleCPU,TimingSimpleCPU,O3CPU,InOrderCPU'
PROTOCOL =
I'll check those errors out for you, but InOrder doesnt currently work in FS
mode, so you would be OK to remove that from your build options if you so
chose.
On Tue, Jan 11, 2011 at 11:14 PM, Sage leonard...@gmail.com wrote:
Hello, everyone,
In the m5-dev version, I was trying to build
I don't know the range of numbers that we deal with, but floating numbers
may not exactly represent integers. It is possible to construct integers
2^53 which are not exactly representable, I think (2^53)+1 cannot be
represented exactly. In fact, in such a case, 'a++' might end up equal to
'a'
I don't know the range of numbers that we deal with, but floating numbers
may not exactly represent integers. It is possible to construct integers
2^53 which are not exactly representable, I think (2^53)+1 cannot be
represented exactly. In fact, in such a case, 'a++' might end up equal to
Hi, Korey,
Thanks for your reply. But even after I removed “InOrderCPU” from the
CPU_MODELS list and cleaned up the build folder, source files related to
the inorder model would still be compiled and the same errors would show up
again.
Thanks,
Leonard
On Tue, Jan 11, 2011 at 10:36 PM, Korey
We should be discussing this on m5-users, and it's probably better to
set those parameters on the scons command line than in the file with the
default settings. If you run scons --help, or scons --help
build/ALPHA_SE_MOESI_CMP_directory/m5.opt in this case, it will print
out what setting it's
Actually, I intended to configure a ruby memory hierarchy with a mesh
topology and full system support. I had no problem building
build/ALPHA_SE_MOESI_CMP_directory/m5.opt at all.
But if I run build/ALPHA_SE_MOESI_CMP_directory/m5.opt -re
tests/run.py
24 matches
Mail list logo
