| Age | Commit message (Collapse) | Author |
|---|
|
|
|
--HG--
rename : src/mem/ruby/eventqueue/EventQueue.cc => src/mem/ruby/eventqueue/RubyEventQueue.cc
rename : src/mem/ruby/eventqueue/EventQueue.hh => src/mem/ruby/eventqueue/RubyEventQueue.hh
rename : src/mem/ruby/eventqueue/EventQueueNode.cc => src/mem/ruby/eventqueue/RubyEventQueueNode.cc
rename : src/mem/ruby/eventqueue/EventQueueNode.hh => src/mem/ruby/eventqueue/RubyEventQueueNode.hh
|
|
|
|
I did the macro cleanup because I was worried that the SCons scanner
would get confused. This code will hopefully go away soon anyway.
--HG--
rename : src/mem/ruby/config/config.include => src/mem/ruby/config/config.hh
|
|
|
|
We eventually plan to replace the m5 cache hierarchy with the GEMS
hierarchy, but for now we will make both live alongside eachother.
|
|
|
|
Previously there was one per bus, which caused some coherence problems
when more than one decided to respond. Now there is just one on
the main memory bus. The default bus responder on all other buses
is now the downstream cache's cpu_side port. Caches no longer need
to do address range filtering; instead, we just have a simple flag
to prevent snoops from propagating to the I/O bus.
|
|
|
|
|
|
|
|
This frees up needed space for more public flags. Also:
- remove unused Request accessor methods
- make Packet use public Request accessors, so it need not be a friend
|
|
|
|
|
|
|
|
|
|
delivered.
|
|
|
|
|
|
|
|
|
|
|
|
been tested on Alpha, compiles for the rest but not tested. I don't see why it wouldn't work though.
|
|
Apparently we broke it with the cache rewrite and never noticed.
Thanks to Bao Yungang <baoyungang@gmail.com> for a significant part
of these changes (and for inspiring me to work on the rest).
Some other overdue cleanup on the prefetch code too.
|
|
Scons bug id: 2006 M5 Bug id: 308
|
|
|
|
Bogus calls to ChunkGenerator with negative size were triggering
a new assertion that was added there.
Also did a little renaming and cleanup in the process.
|
|
I think readData() and writeData() were used for Erik's compression
work, but that code is gone, these aren't called anymore, and they
don't even really do what their names imply.
|
|
I did some of the flags and assertions wrong. Thanks to Brad Beckmann
for pointing this out. I should have run the opt regressions instead
of the fast. I also screwed up some of the logical functions in the Flags
class.
|
|
|
|
Move the constructor into the .cc file and get rid of the typedef for
SendEvent.
|
|
|
|
Would have saved me much debugging time if these
had been in there previously.
|
|
Makes adding write-through operations easier.
|
|
|
|
connotations for what is really happening and how it should be used.
|
|
redundancies with threadId() as their replacement.
|
|
the primary identifier for a hardware context should be contextId(). The
concept of threads within a CPU remains, in the form of threadId() because
sometimes you need to know which context within a cpu to manipulate.
|
|
comments.
|
|
|
|
|
|
HG: user: Lisa Hsu <hsul@eecs.umich.edu> HG: branch default HG: changed
src/mem/cache/cache.hh
|
|
|
|
memory range.
|
|
|
|
For now, there is still a single global event queue, but this is
necessary for making the steps towards a parallelized m5.
|
|
Since the early days of M5, an event needed to know which event queue
it was on, and that data was required at the time of construction of
the event object. In the future parallelized M5, this sort of
requirement does not work well since the proper event queue will not
always be known at the time of construction of an event. Now, events
are created, and the EventQueue itself has the schedule function,
e.g. eventq->schedule(event, when). To simplify the syntax, I created
a class called EventManager which holds a pointer to an EventQueue and
provides the schedule interface that is a proxy for the EventQueue.
The intent is that objects that frequently schedule events can be
derived from EventManager and then they have the schedule interface.
SimObject and Port are examples of objects that will become
EventManagers. The end result is that any SimObject can just call
schedule(event, when) and it will just call that SimObject's
eventq->schedule function. Of course, some objects may have more than
one EventQueue, so this interface might not be perfect for those, but
they should be relatively few.
|
|
|
|
should configure their editors to not insert tabs
|
|
|
