Searched hist:5605 (Results 1 - 7 of 7) sorted by relevance
| /gem5/src/python/m5/ | ||
| H A D | event.py | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
| /gem5/src/sim/ | ||
| H A D | eventq.cc | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
| H A D | sim_object.hh | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
| H A D | sim_object.cc | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
| H A D | eventq.hh | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
| /gem5/src/mem/ | ||
| H A D | port.cc | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
| H A D | port.hh | 5605:b194a80157e2 Thu Oct 09 07:58:00 EDT 2008 Nathan Binkert <nate@binkert.org> eventq: Major API change for the Event and EventQueue structures. 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. |
Completed in 83 milliseconds