scons: *** [build/ALPHA/gem5.opt] Error 1
*
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
passed.
*
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
passed.
*
changeset b7ff344c3061 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=b7ff344c3061
description:
stats: Update stats to reflect x86 table walker changes
diffstat:
tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/stats.txt | 106
+-
changeset 8bb4a9717eaa in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=8bb4a9717eaa
description:
mem: Always use SenderState for response routing in RubyPort
This patch aligns how the response routing is done in the RubyPort,
using the SenderState for
changeset bd376adfb7d4 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=bd376adfb7d4
description:
mem: Make the XBar responsible for tracking response routing
This patch removes the need for a source and destination field in the
packet by shifting the
changeset e3fc6bc7f97e in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e3fc6bc7f97e
description:
mem: Clean up Request initialisation
This patch tidies up how we create and set the fields of a Request. In
essence it tries to use the constructor where
changeset e49bf4884c59 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=e49bf4884c59
description:
x86: Delay X86 table walk on receiving walker response
This patch fixes a minor issue in the X86 page table walker where it
ended up sending new request
changeset 87f7b5a07584 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=87f7b5a07584
description:
mem: Remove unused Packet src and dest fields
This patch takes the final step in removing the src and dest fields in
the packet. These fields were rather
changeset a0dab21e422f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=a0dab21e422f
description:
sim: fix reference counting of PythonEvent
When gem5 is a slave to another simulator and the Python is only used
to initialize the configuration (and not
changeset 3a3bb559b112 in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=3a3bb559b112
description:
mem: Remove Packet source from ForwardResponseRecord
This patch removes the source field from the ForwardResponseRecord,
but keeps the class as it is part
changeset 1de300588c4f in /z/repo/gem5
details: http://repo.gem5.org/gem5?cmd=changeset;node=1de300588c4f
description:
mem: Remove unused RequestState in the bridge
This patch removes the bridge sender state as the Crossbar now takes
care of remembering its own routing
From AMD's system programming manual:
SYSCALL
New selectors are loaded, without permission checking (see above), as follows:
Bits 47:32 of the STAR register specify the selector that is copied into the CS
register.
Bits 47:32 of the STAR register + 8 specify the selector that is copied into
Hello,
How can I force a request to be uncacheable when using Ruby memory
system?req-setFlags(Request::UNCACHEABLE) works for classic memory system
but it doesn't have any effect on the request while using Ruby.
Thank you,Mohammad
___
gem5-dev mailing
Hey Gabe,
Thanks for the suggestion. This work-around doesn't appear to work. In
the O3CPU, the instruction still does not get committed due to the fault
(DefaultCommitImpl::commitHead(suspend instruction) generates a trap
and returns that the instruction cannot be committed). After thread
Hello,
I'm trying to get the vfp/simd register values during simulation. I
find a clue in src/cpu/simple_thread.hh, there defined an array
`FloatReg f[TheISA::NumFloatRegs];`. Also I checked
ArmISA::NumFloatRegs value. It's 160.
Can I get V0-V31 register values by reading the FloatReg array?
OK,
I believe I have a patch that unifies the code for both AMD and Intel.
Do I post it as a separate review-board item?
On Thu, Jan 22, 2015 at 11:32 AM, mike upton michaelup...@gmail.com wrote:
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2557/
Glad you all seem to be figuring this out. I think we should do runtime
rather than compile-time detection though, as some people may have mixed
clusters they want to run the same binary on, or may cross-compile.
Steve
On Wed, Jan 21, 2015 at 3:30 PM, Dutu, Alexandru via gem5-dev
On Jan. 21, 2015, 9:22 p.m., mike upton wrote:
src/arch/x86/process.cc, lines 218-237
http://reviews.gem5.org/r/2557/diff/2/?file=42948#file42948line218
For AMD systems, the sys descriptors need to come first. On intel
systems they need to come second.
I do not know
Hello,
I am writing a trace probe for AtomicSimpleCPU. The simulation is
planed to run in SE mode. For user-level instruction, I can get
address and data of memory access by *traceData* member in
BasicSimpleCPU. But for system call, I don't know how to collect the
memory change during the syscall
18 matches
Mail list logo
