* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing
passed.
= Statistics differences ==
On Tue, Jan 4, 2011 at 10:09 PM, nathan binkert n...@binkert.org wrote:
Neat idea, but you need to check sys.stdout.isatty() and conditionally
add the color. Then you're going to want a way to override that if
you're
piping through less :) Seems like we could add a --color option to the
As a thought, TRANSFORM should probably take the action abbreviation
(e.g. CC) as a parameter if you're going to do the colorization.
I don't follow... do you think the filenames should be colorized differently
depending on the command? Note that the TRANSFORM* functions don't get
called
1. Below is a snip of a protocol trace that I recently used. I think it
is important for us maintain that there is no DPRINTF information prepended to
each line. The initial motivation for the protocol trace, was that tracing
protocol transitions using standard debug print was too
On 2010-12-21 17:29:39, Steve Reinhardt wrote:
src/arch/arm/tlb.cc, line 562
http://reviews.m5sim.org/r/342/diff/1/?file=5459#file5459line562
It seems to me like we ought to have a generic check in the CPU models
that prevents prefetches to uncacheable locations rather than
Brad,
This how protocol trace would look like. I actually did not some such
thing exists. I was currently relying on DPRINTF statements for checking
the events that occurred. This is certainly easier to read and much more
compact.
1395: system.l1_cntrl3:1395 3L1Cache
On Tue, Jan 4, 2011 at 5:56 PM, nathan binkert n...@binkert.org wrote:
I want to keep this a purely syntactic change, because I think the semantic
changes are going to require some discussion. For example, my current
next-step patch replaces mainEventQueue with an array of queues (so there
Looks like we should just remove the first, second, and third columns
that are spit out since they're covered almost exactly by the implicit
columns added by DPRINTF. Right?
Nate
This how protocol trace would look like. I actually did not some such
thing exists. I was currently relying on
1. Below is a snip of a protocol trace that I recently used. I
think it is important for us maintain that there is no DPRINTF information
prepended to each line. The initial motivation for the protocol trace, was
that tracing protocol transitions using standard debug print was too
Is it possible to fix the width of the information prepended by DPRINTF? I
would be great if we could maintain the current fixed width format.
Brad
-Original Message-
From: bink...@gmail.com [mailto:bink...@gmail.com] On Behalf Of nathan binkert
Sent: Wednesday, January 05, 2011 10:36
So if we explicitly handled the SIGABRT signal, we would only want to do that
if we are running interactively, correct? If so, then we would still have some
sort of conditional similar, if not the same as, the current conditional in the
assert macro if (isatty(STDIN_FILENO)). If my
It's a flexibility/fear-of-commitment thing... initially I wasn't positive
which way I would go, and once I decided that
curTick-as-EventQueue/Manager-field wasn't going to work well (too many
places where it's pretty awkward to find the object pointer), I figured it
would still be useful in
Is it possible to fix the width of the information prepended by DPRINTF? I
would be great if we could maintain the current fixed width format.
That might be hard (and may argue for DPRINTFN). In practice, when I
want that, I usually just ensure that my object names end up not
varying in
So if we explicitly handled the SIGABRT signal, we would only want to do
that if we are running interactively, correct? If so, then we would still
have some sort of conditional similar, if not the same as, the current
conditional in the assert macro “if (isatty(STDIN_FILENO))”. If my
Yeah, that seems rather tedious. Let's just use DPRINTFN and maintain the
current format. As long as the protocol trace format looks the same as before,
I'm happy with the change.
Brad
-Original Message-
From: bink...@gmail.com [mailto:bink...@gmail.com] On Behalf Of nathan binkert
Hi Nilay,
Lisa Hsu (another member of the lab here at AMD) and I were discussing these
changes a bit more and there was one particular idea that came out of our
conversation that I wanted to relay to you. Basically, we were thinking about
how these changes will impact the flexibility of SLICC
16 matches
Mail list logo
