I don't have anything constructive to add, but the interrupt stuff I
added to x86 could make use of a real broadcast if that happens.
Gabe
nathan binkert wrote:
>> However, the question is: when we move to interconnects that decouple
>> these two things, what entity becomes responsible for mappin
> However, the question is: when we move to interconnects that decouple
> these two things, what entity becomes responsible for mapping
> addresses to destinations? There must be some logic or a routing
> table that uses the address to generate a destination ID. Without
> having given it a ton of
Seems like if it's a cacheable address that's not in the cache you'd
want to bring in an exclusive copy and go from there. Can't see why
you'd want to treat hits and misses differently.
Locked uncached accesses are another story... I don't know how they're
done in our current machines (probably c
On Wed, Nov 5, 2008 at 7:57 PM, nathan binkert <[EMAIL PROTECTED]> wrote:
>> Yea, Ali's got it right... the way to think about address-based
>> routing on the bus is that the packet logically does get broadcast to
>> determine the destination; all our mucking with address ranges is
>> really just s
> Yea, Ali's got it right... the way to think about address-based
> routing on the bus is that the packet logically does get broadcast to
> determine the destination; all our mucking with address ranges is
> really just some combination of optimization and sanity check.
I buy that, but I'd argue th
Yea, Ali's got it right... the way to think about address-based
routing on the bus is that the packet logically does get broadcast to
determine the destination; all our mucking with address ranges is
really just some combination of optimization and sanity check.
As far as the setSrc() calls in mem
The source/dest ids are only valid within a single interconnection.
Source is automatically set by the bus when it's received an a port.
Dest currently used to either route the request back to the original
source, or to instruct the interconnect to locate the proper port.
Broadcast makes se
Ok, I've read the code a bit more, and it seems clear that dest needs
to be sent by the sender. So this means that the sender needs to know
the topology of the network (or at least the node id) of an object on
the other side? For responses, this makes sense, you want to respond
to the guy who sen
I'm trying to understand exactly how these should be used. Are they
intended to be used entirely internally to an interconnect? i.e. just
within the bus or crossbar or mesh or whatever? I want a source and
destination for my crossbar model, but I don't want to break things.
I'm slightly confused
changeset 11e6f4fa85c3 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=11e6f4fa85c3
description:
new mp eio test
diffstat:
10 files changed, 1243 insertions(+), 1 deletion(-)
tests/SConscript |1
tests/quick/30.eio-mp/
changeset 8d96bbe4cc84 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=8d96bbe4cc84
description:
Automated merge with ssh://m5sim.org//repo/m5
diffstat:
0 files changed
diffs (24 lines):
diff -r 11e6f4fa85c3 -r 8d96bbe4cc84 src/arch/sparc/ua2005.cc
--- a/src/arch/spar
changeset df9253dd6b4d in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=df9253dd6b4d
description:
Fix a few more places where the context stuff wasn't changed
diffstat:
0 files changed
diffs (24 lines):
diff -r c9056088f151 -r df9253dd6b4d src/arch/sparc/ua2005.cc
---
I just looked, and the manual says that if a value is already in a cache it's
just locked there. I think if it's not, then there's a lock signal on the bus
which prevents anyone else from using it while the sensitive instruction is
running. Normally the value would migrate up into the cache anyway
I am officially appeased. :)
Gabe
Quoting [EMAIL PROTECTED]:
> changeset 324547c99895 in /z/repo/encumbered
> details: http://repo.m5sim.org/encumbered?cmd=changeset;node=324547c99895
> summary: appease gabe, fatal out if EioProcess attempts to start up in a
> non-ALPHA ISA
>
> diffstat:
>
> 1 f
changeset 324547c99895 in /z/repo/encumbered
details: http://repo.m5sim.org/encumbered?cmd=changeset;node=324547c99895
summary: appease gabe, fatal out if EioProcess attempts to start up in a
non-ALPHA ISA
diffstat:
1 file changed, 2 insertions(+)
eio/eio.cc |2 ++
diffs (14 lines):
diff -r
changeset c9056088f151 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c9056088f151
description:
Fix SPARC_FS compile
diffstat:
0 files changed
diffs (12 lines):
diff -r 323cfbfec1a4 -r c9056088f151 src/dev/sparc/iob.cc
--- a/src/dev/sparc/iob.cc Wed Nov 05 15:30
changeset 323cfbfec1a4 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=323cfbfec1a4
description:
Right now a single thread cpu 1 could get assigned context Id != 1,
depending
on the order in which it's registered with the system. To make them
match,
her
I want to understand how the bus work using the xxgdb to trace m5.debug, but
i can't find the bus.cc scheduled by m5.debug. Can you tell me how the
m5.debug call bus.cc to work and which files connect with bus.cc. I mean if
i want to modify the bus.cc for our cross-bar application, which file we
This would be a different type of lock than an Alpha load-locked
(which isn't really a lock, hence the alternate term "load linked" is
really more descriptive). I'm expecting that with x86 lock prefixes
you really do have to acquire an exclusive copy up front and literally
lock it in the cache bef
Doing it with micro-ops seems tricky. At least for SPARC. Lets say two
caches lock the the same line for a compare-and-swap. The reads happen
for the compare and the compare matches, so the processor issues a
write to the locked line. Although the writes will be ordered, what
happens when t
On Nov 5, 2008, at 2:01 AM, Gabe Black wrote:
>Looking into this more, there are two problems. First, it looks
> like
> Alpha is passing back it's store conditional result in the extra data
> part of the request. I think for regular swaps this is actually the
> data
> to swap in, and for
I forgot about swaps... I was in an Alpha-centric frame of mind.
Maybe if we have to implement truly locked memory accesses for x86
(i.e., read-modify-write where the read, modify, and write are
separate microops) then we should redo SPARC swaps using the same
technique and get them out of the cach
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/
23 matches
Mail list logo
