* build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
*
I injured my eye the other day and had some visitors from out of
town, so I've been out of commission for the last several days. Now that
I'm mostly back in the saddle, I've started working on getting the
simple timing CPU working under x86. It's been going smoothly, but one
issue that's come
This patch resolves the issue that I posted to the M5 Users list. The
API change to EventWrapper did not get propagated to the entirety of
TimingSimpleCPU. The patch works on both the tip of both stable and
unstable. I left in the deschedule right before the schedule, but it
may
I think I must be missing something. How are x86 unaligned accesses
handled now? 1 unaligned access - 3 aligned accesses that are
combined? What chops them into piece? microcode? Some other means?
The issue is that an access could span a page boundary so half of it
could be in the TLB
# HG changeset patch
# User Clint Smullen [EMAIL PROTECTED]
# Date 1225151161 14400
# Node ID e376c3efb9f80f93ba3534341b83cff56f483485
# Parent 6b707147a89ce576643b0f29b41c76017ea9e651
imported patch drainevent_fix
diff --git a/src/python/swig/pyevent.cc b/src/python/swig/pyevent.cc
---
I encountered a small bug where a m5.drain(test_sys) that was
triggered by a m5_switchcpu call that occurs within a workload (rather
than as part of a script) produced the following error:
Traceback (most recent call last): File string, line 1, in
module File
In the atomic simple CPU, they're broken up across the CPU's peers
blocksize aligned boundaries by the CPU and done as x different
accesses, usually 1 or 2. There may be some weird case were it's more
than 2, but I can't think of any off the top of my head. The CPU then
composites the results into
There's also the possibility that these accesses could be atomic, right?
On Mon, Oct 27, 2008 at 5:33 PM, Gabe Black [EMAIL PROTECTED] wrote:
In the atomic simple CPU, they're broken up across the CPU's peers
blocksize aligned boundaries by the CPU and done as x different
accesses, usually 1
OK... so if we have to have the ability to lock a block in the cache
for the duration of the instruction, then how those blocks get in
there wrt TLB accesses is moot? That sounds plausible to me. Just
want to make sure that if there is an interaction that we don't design
something now that we
I still don't get what is doing the cutting into pieces? Is it done by
the CPU? or does the cpu execute two instructions to fill portions of
a register?
Ali
On Oct 27, 2008, at 6:19 PM, Gabe Black wrote:
I think so, if I'm understanding you right. I looked in the manuals,
and
in the
The CPU.
Ali Saidi wrote:
I still don't get what is doing the cutting into pieces? Is it done by
the CPU? or does the cpu execute two instructions to fill portions of
a register?
Ali
On Oct 27, 2008, at 6:19 PM, Gabe Black wrote:
I think so, if I'm understanding you right. I
Hacking on this a little more, I've come across another wrinkle. The
functions which finish a timing memory access expect to get a packet
which has their data. That means that if multiple accesses are required,
the CPU will have to take all the packets it gets as responses and build
a larger
12 matches
Mail list logo
