---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/347/#review527
---
Seems ok, but what's the story behind why this change was necessary?
-
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/348/#review528
---
Looks ok. While the commit message is mostly ok it would benefit from
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/349/#review529
---
src/cpu/o3/iew_impl.hh
http://reviews.m5sim.org/r/349/#comment785
scons: *** Found dependency cycle(s):
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
*
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/312/
---
(Updated 2010-12-09 01:57:37.367475)
Review request for Default.
Summary
---
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/350/
---
Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan
On 2010-12-08 22:30:12, Gabe Black wrote:
Could you please explain the reason for this change? I'm not familiar
enough with ARM's interrupt architecture to know what the commit message is
saying. My guess is that the interrupt controller initially thought it was
going to signal an
On 2010-12-09 00:05:46, Gabe Black wrote:
src/cpu/o3/iew_impl.hh, line 1298
http://reviews.m5sim.org/r/349/diff/1/?file=5479#file5479line1298
Wouldn't just checking !inst-isExecuted be sufficient? If it hasn't
executed yet I don't think it shouldn't be checked for a mispredict no
changeset 9bd6b37d0189 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9bd6b37d0189
description:
ARM: Get rid of some unused FP operands.
diffstat:
src/arch/arm/isa/operands.isa | 5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diffs (15 lines):
diff -r
changeset 998b217dcae7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=998b217dcae7
description:
ARM: Take advantage of new PCState syntax.
diffstat:
src/arch/arm/isa/insts/branch.isa | 55 ++
src/arch/arm/isa/insts/data.isa |9 +-
On 2010-12-08 23:56:50, Gabe Black wrote:
Malformed commit message again.
It would be nice not to lose the information in the commit message. Ideally
it would pop out if the fault was invoked in SE mode, but more trivially it
could be moved into a comment above the new version.
On 2010-12-08 23:56:50, Gabe Black wrote:
Malformed commit message again.
It would be nice not to lose the information in the commit message. Ideally
it would pop out if the fault was invoked in SE mode, but more trivially it
could be moved into a comment above the new version.
On 2010-12-08 22:45:44, Gabe Black wrote:
src/arch/isa_parser.py, line 795
http://reviews.m5sim.org/r/339/diff/1/?file=5449#file5449line795
These values aren't passed directly to anything, they're exposed
through a header file and then imported into the ArmISA namespace in
On 2010-12-08 22:45:44, Gabe Black wrote:
src/arch/isa_parser.py, line 795
http://reviews.m5sim.org/r/339/diff/1/?file=5449#file5449line795
These values aren't passed directly to anything, they're exposed
through a header file and then imported into the ArmISA namespace in
Hi Brad
Is there way to access the StateMachine object inside any of the AST class
functions? I know the name of the machine can be accessed. But can the
machine itself be accessed? I need one of the variables in the
StateMachine object to know whether or not TBETable exists in this
machine.
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/342/#review536
---
src/cpu/o3/iew_impl.hh
http://reviews.m5sim.org/r/342/#comment793
On 2010-12-09 18:42:27, Ali Saidi wrote:
src/cpu/o3/iew_impl.hh, line 1235
http://reviews.m5sim.org/r/342/diff/1/?file=5460#file5460line1235
So the code outside the if block executes normally and the prefetch, if
it faults, just silently goes away.
Oh, I got it now. I
Hi Ali,
I just synced with this changeset 7733, as well as changeset 7730, and I now
notice that the modifications to physical.cc break all previous checkpoints.
Can we put the lal_addr and lal_cid serialization and unserialization in a
conditional that tests for the ARM ISA? I welcome other
Hi Ali,
This is changset 7730 which also breaks all previous checkpoints because it
requires phsymem to serialize and unserialize the variable _size.
Brad
-Original Message-
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Ali Saidi
Sent: Monday,
In reference to this and the next email, I don't think these should be
conditioned on the ARM ISA because it looks like those values are
valid and need to be serialized for all ISAs. It's just that the other
ISAs happen to have checkpoints that are old enough that they break,
and that's
Hi Nilay,
Yes, I believe a machine can be accessed within AST class functions, though I
don't remember ever doing it myself. Look at the generate() function in
TypeFieldEnumAST. Here you see that the machine (a.k.a StateMachine) is
grabbed from the symbol table and then different
Thanks Gabe.
Yeah, I don't think conditioning on the ARM ISA for this change is necessarily
a good idea. I just suggested it to see if there was some sort of conditional
we could add. As far as the _size parameter goes, it is not clear to me why
that needs to be in the checkpoint. Isn't the
It works perfectly. Thanks!
Nilay
On Thu, 9 Dec 2010, Beckmann, Brad wrote:
Hi Nilay,
Yes, I believe a machine can be accessed within AST class functions, though I
don't remember ever doing it myself. Look at the generate() function in
TypeFieldEnumAST. Here you see that the machine
Right, I don't want to sound like those sort of changes should just be
done cavalierly. I'm just saying we shouldn't be afraid to make them
when we need to.
Gabe
Quoting Beckmann, Brad brad.beckm...@amd.com:
Thanks Gabe.
Yeah, I don't think conditioning on the ARM ISA for this change is
24 matches
Mail list logo
