* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby
passed.
* build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby
passed.
* build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed.
*
I'll post a reviewboard patch for the name change soon.
On Thu, Apr 21, 2011 at 11:24 AM, Beckmann, Brad brad.beckm...@amd.comwrote:
Ha...those latency values have been referred to as miss latencies for so
long that I failed to realize that calling them miss latencies would be
confusing.
(inline)
One psychological solution would be to reduce the amount of output from
SLICC, making it a less obvious target for annoyance when you're waiting
for
a build...
Along this same line of thought, it may be easier in the interim to print
out something like Continuing build ... or SLICC
I don't have a strong opinion, and I'm not 100% sure I'm even following this
correctly (I just skimmed the thread), but I think access latency (or
effective or average access latency) would be the term that's most
self-explanatory. To me request latency is a little ambiguous, since I
believe
On 2011-04-22 18:51:32, Nathan Binkert wrote:
src/mem/cache/base.hh, line 503
http://reviews.m5sim.org/r/654/diff/1/?file=11759#file11759line503
This can pretty easily be done with a template:
template class STAT
void
incThreadVectorStat(PacketPtr pkt, STAT
I have a plan for how to fix this which won't be that difficult, but
since it's going to be near the heart of all the x86 instruction
machinery I'd like to be able to test it. I could put together a
specialized test case which has a malformed instruction that should hit
this even in the simple
Never mind. The test was easy to write.
Gabe
On 04/23/11 13:55, Gabe Black wrote:
I have a plan for how to fix this which won't be that difficult, but
since it's going to be near the heart of all the x86 instruction
machinery I'd like to be able to test it. I could put together a
specialized
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/651/#review1147
---
Did you use hg mv? The diff doesn't seem to include that information,
On 2011-04-18 21:20:49, Nathan Binkert wrote:
util/gem5img.py, line 64
http://reviews.m5sim.org/r/644/diff/1/?file=11664#file11664line64
This is pretty similar to m5.util.readCommand which made me think that
it might be nice if we put your utility functions here in m5.util
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/653/#review1149
---
The main question I have about this code is, should new Ruby code adhere
I looked at it and it is similar, but it's different enough that they can't
be interchanged. My functions all allow passing a string in as standard input
and return the error code, but readCommand doesn't. I could extend it to take
an input string, but it's not clear how to return the
On 04/23/11 23:49, nathan binkert wrote:
I looked at it and it is similar, but it's different enough that they can't
be interchanged. My functions all allow passing a string in as standard
input and return the error code, but readCommand doesn't. I could extend it
to take an input string,
All that said, if you want to take the script and move things into
m5.util, or rework it so it uses m5.util, or make it handle paths
better, or whatever, I certainly won't try to stop you. I think my
version is an improvement over the original, but it's definitely not
perfect.
I didn't mean
On 04/24/11 00:14, nathan binkert wrote:
All that said, if you want to take the script and move things into
m5.util, or rework it so it uses m5.util, or make it handle paths
better, or whatever, I certainly won't try to stop you. I think my
version is an improvement over the original, but it's
14 matches
Mail list logo
