On Jun 29, 2008, at 10:53 PM, Ali Saidi wrote:
On Jun 29, 2008, at 8:28 PM, Steve Reinhardt wrote:
On Sun, Jun 29, 2008 at 4:49 PM, Ali Saidi [EMAIL PROTECTED]
wrote:
one question
is how to enforce encourage objects that call getVirtPort() to not
cache the virtual port
since if the CPU
On Mon, Jun 30, 2008 at 8:26 AM, Ali Saidi [EMAIL PROTECTED] wrote:
On the other hand, if during the switchover the new CPU starts
connecting to the same ports that the old one did, won't my once and
future patch mean that the old CPU's port gets dicsonnected and
hooked
up to a defaultPort,
On Jun 30, 2008, at 5:15 PM, Steve Reinhardt wrote:
On Mon, Jun 30, 2008 at 9:11 AM, Ali Saidi [EMAIL PROTECTED] wrote:
The FastAlloc pools and StaticInst cache should clearly be
duplicated.
Why would you want to duplicate the StaticInst cache? It's a
read-mostly structure so you'd only
OK, that makes more sense now. Still seems like in the long term the
right thing is to use a data structure that supports multiple readers
with either per-bucket locks, a reader/writer lock, or some sort of
non-blocking update (has x86 added a compare-and-swap yet?).
They've had cmpxchg
Yes. CMPXCHG on page 98 of volume 3 of the AMD manuals. It says it
supports the lock prefix so I'm assuming it's not otherwise atomic.
Gabe
non-blocking update (has x86 added a compare-and-swap yet?).
___
m5-dev mailing list
m5-dev@m5sim.org
