* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
*
I don't think you really need to be able to cancel those events if
every distinct hardware-event was simulated. In case of a mispredicted
instruction the immediately following events don't necessarily need to
commit any lasting cpu state changes just like in a real out of order
cpu. So I'm
# HG changeset patch
# User Timothy M. Jones tjon...@inf.ed.ac.uk
# Date 1257772283 0
# Node ID 861198113ecaf172b6d1e874cda4d13c92bdb38a
# Parent e9f450b4b4f276dd3ed69dd63a540dda2796de60
Power ISA: Add an alignment fault to Power ISA and check alignment in TLB.
diff --git
These patches enable Power ISA benchmarks to run on O3CPU through the
following changes:
1) An alignment fault is added to the Power ISA.
2) The TLB translation mechanism is altered from atomic to timing.
3) Loads and stores are split in half if they cross a cache line boundary.
The majority of
# HG changeset patch
# User Timothy M. Jones tjon...@inf.ed.ac.uk
# Date 1257772288 0
# Node ID da27e67385cca6cf4dd6d18cdead5cfd54559afb
# Parent 861198113ecaf172b6d1e874cda4d13c92bdb38a
BaseDynInst: Make the TLB translation timing instead of atomic.
This initiates a timing translation and
# HG changeset patch
# User Timothy M. Jones tjon...@inf.ed.ac.uk
# Date 1257772288 0
# Node ID 1c63ee4b8afa271d3ae645419e37913bbb97fe6b
# Parent da27e67385cca6cf4dd6d18cdead5cfd54559afb
O3PCU: Split loads and stores that cross cache line boundaries.
When each load or store is sent to the LSQ,
changeset 2e67bb7c9b4c in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=2e67bb7c9b4c
description:
syscall: missing initializer in getcwd call
This one case was missed during the update to stack-based arguments.
Without this fix, m5 will crash during a
Gabe, can you send out your patches inline, not as attachments? Did
you switch intentionally? It makes it harder to comment on your
changes.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
nathan binkert wrote:
Gabe, can you send out your patches inline, not as attachments? Did
you switch intentionally? It makes it harder to comment on your
changes.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
I thought I had... My command line is below, and I thought that's what
-i did.
hg email -r 6731:6734 -g -i -t 'm5-dev@m5sim.org'
That's odd. Anything strange with your .hgrc? (by the way, you can
put all of -g -i and -t into your .hgrc as defaults)
[defaults]
email = --git
[email]
method =
I don't think you really need to be able to cancel those events if every
distinct hardware-event was simulated. In case of a mispredicted instruction
the immediately following events don't necessarily need to commit any
lasting cpu state changes just like in a real out of order cpu. So I'm
Did you pull the code in translation.hh out of cpu/simple/timing.hh?
If so, does it need to remain? I'd prefer not to have to copies of
the same code floating around.
Nate
On Mon, Nov 9, 2009 at 5:30 AM, Timothy M. Jones tjon...@inf.ed.ac.uk wrote:
# HG changeset patch
# User Timothy M.
Do we really want to page fault on a prefetch? I can see a TLB fill,
but a fault? (or are these wrapped into one thing?)
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Is there a chance you can resend these so they're in individual
e-mails? It's tough to wade through this way.
Thanks,
Nate
On Mon, Nov 9, 2009 at 10:38 AM, Beckmann, Brad brad.beckm...@amd.com wrote:
-- Forwarded message --
From: g...@cmdmail.amd.com
To: Beckmann, Brad
Actually, perhaps you should wait one week.
My guess is that nobody can really read them carefully right now.
Nate
On Mon, Nov 9, 2009 at 2:00 PM, nathan binkert n...@binkert.org wrote:
Is there a chance you can resend these so they're in individual
e-mails? It's tough to wade through this
Are you referring to the PageFault in the SE only code in the TLB?
It's really just a signal to the CPU that the translation failed. If
the translation failure was silent, the CPU might still try to do the
access and cause more trouble. Once the fault makes it into the CPU,
it gets
On Sun, 8 Nov 2009, Gabe Black wrote:
I can definitely see how this would be a pain to find, and I'm surprised
a benchmark was so sensitive.
Well, one of the symptoms is an off-by-one error, which doesn't sound like
much, but after a subtraction this changed a multiplier from 1 to 2 which
Ok, that all makes sense. I didn't realize that it was squashed.
Nate
On Mon, Nov 9, 2009 at 2:03 PM, Gabriel Michael Black
gbl...@eecs.umich.edu wrote:
Are you referring to the PageFault in the SE only code in the TLB? It's
really just a signal to the CPU that the translation failed. If
Sure I can send them individually. I'll go ahead a do that before I forget.
I completely understand it may take a week before people can review them. As
long as there are no other major changes checked into ruby in the meantime, I
don't mind waiting at all.
Brad
-Original Message-
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 01 of 31] ruby: Ruby memtest python script
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791381 28800
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 02 of 31] ruby: Ruby debug print fixes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791381 28800
# Node
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 04 of 31] ruby: Ruby 64-bit address output fixes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 03 of 31] ruby: Ruby destruction fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382 28800
# Node ID
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 05 of 31] ruby: Added more info to bridge error message
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 07 of 31] ruby: Added error check for openning the ruby
configfile
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 06 of 31] ruby: Support for merging ALPHA_FS and ruby
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 08 of 31] ruby: included ruby config parameter ports per
core
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 09 of 31] m5: Added isValidSrc and isValidDest calls
topacket.hh
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 10 of 31] m5: Moved profile option since Simulation
depends onit
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 11 of 31] ruby: Fixed Directory memory destructor
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 12 of 31] ruby: getPort function fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382 28800
# Node ID
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 13 of 31] m5: fixed destructor to deschedule the
tickEvent andevent
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 17 of 31] m5: Added option to take a checkpoint at the
end ofsimulation
# HG changeset patch
# User Brad Beckmann
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 14 of 31] m5: removed master and slave deletions
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791382
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 19 of 31] ruby: slicc state machine error fixes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:32 AM
To: Beckmann, Brad
Subject: [PATCH 18 of 31] ruby: Removed unused action z_stall
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 20 of 31] ruby: slicc action error fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
# Node
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 21 of 31] ruby: slicc method error fix
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
# Node
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 22 of 31] ruby: Added default names to message buffers
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 23 of 31] ruby: split CacheMemory.hh into a .hh and a
.cc
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 25 of 31] ruby: cache configuration fix to use bytes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 24 of 31] ruby: fix CacheMemory destructor
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791383 28800
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 26 of 31] ruby: returns the number of LLC needed for
broadcast
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 27 of 31] ruby: added the original hammer protocols from
oldruby
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 29 of 31] ruby: Hammer ruby configuration support
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date 1257791384
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 30 of 31] ruby: Added a memory controller feature to
MOESIhammer
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
#
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 28 of 31] ruby: Changes necessary to get the hammer
protocolto work in GEM5
# HG changeset patch
# User Brad Beckmann
-Original Message-
From: g...@cmdmail.amd.com [mailto:g...@cmdmail.amd.com]
Sent: Monday, November 09, 2009 10:33 AM
To: Beckmann, Brad
Subject: [PATCH 31 of 31] ruby: MOESI hammer support for DMA reads and
writes
# HG changeset patch
# User Brad Beckmann brad.beckm...@amd.com
# Date
Sure I can send them individually. I'll go ahead a do that before I forget.
I completely understand it may take a week before people can review them. As
long as there are no other major changes checked into ruby in the meantime, I
don't mind waiting at all.
You and Derek will probably
That's true. Brad, we'll talk next week.
On Mon, Nov 9, 2009 at 6:10 PM, nathan binkert n...@binkert.org wrote:
Sure I can send them individually. I'll go ahead a do that before I forget.
I completely understand it may take a week before people can review them.
As long as there are no
On Tue, 3 Nov 2009, Gabe Black wrote:
If you set destSize=8 I think that'll solve the first problem. The
source register is put into a uint64_t, and then that's put into a
destSize sized chunk of the destination register. If you set that to be
8, the uint64_t will take up the whole xmml, and
On Fri, 6 Nov 2009, Gabe Black wrote:
You seem to be missing the majority of the PC relative version... Would
you like to fix that up, or should I?
The blow version properly has the PC relative version, which has been
tested.
Vince
# HG changeset patch
# User Vince Weaver
I didn't get any comments on this patch when I initially posted it.
I've extended the patch to fix all of the ULL issues in the file.
The issue is shifting 1 by more than 32 without putting an ULL on the end.
I checked the other X86 isa files, but they are all fine, it's only the
mediaop.isa
Yes, go for it.
Quoting Vince Weaver vi...@csl.cornell.edu:
On Tue, 3 Nov 2009, Gabe Black wrote:
If you set destSize=8 I think that'll solve the first problem. The
source register is put into a uint64_t, and then that's put into a
destSize sized chunk of the destination register. If you
54 matches
Mail list logo
