I think you're misidentifying the bug here. You should never rely on events being processed in a particular order based on the order they're inserted in the event queue. The whole point of the priorities is to give you explicit control over the order in which events in the same cycle get processed.
If you get different results based on whether events with the same priority on the same cycle get serviced in FIFO or LIFO order then that's the bug, and the fix is to give the events different priorities to make FIFO vs LIFO irrelevant. Steve 2008/5/13 KE MENG <[EMAIL PROTECTED]>: > Well, actually I also reported this as a bug a few months ago. The > difference here is how two events with same priorities and scheduled time > are put in the queue. In current code, later arrived events would be put in > front of other events which have the same priorities and scheduled time, and > this means some later arrived events would get handled first. Under most > circumstances this is probably ok. But for other, it's not neccessarily > appropriate. For example, for an Icache of 1 latency cycle, an > instruction-fetch would put a cache accessing event on the queue. Supposely > it shoud get handled and the instructions would be returned in next cycle. > But since a cpuTick event has a same priority and the tickEvent for next > cycle would be actually put in front of the cache accesing event when it is > scheduled later. So in next cycle, the tickEvent would be handled first and > it has to wait for the access to return yet. In this way, the actual latency > of the Icache becomes 2 cycles. For the same reason, I also changed the > following lines > > if (head == NULL || event->when() < head->when() || > (event->when() == head->when() && > event->priority() <= head->priority())) > > to > > > if (head == NULL || event->when() < head->when() || > (event->when() == head->when() && > event->priority() < head->priority())) > > > Date: Tue, 13 May 2008 05:35:56 -0700 > > From: [EMAIL PROTECTED] > > To: [email protected] > > Subject: Re: [m5-users] a bug report > > > > > The statements are equivalent. It is written the way it is because it > > can fail after just one comparison. In the version that you've shown, > > two comparisons must be made. > > > > Nate > > > > 2008/5/13 fractal218 <[EMAIL PROTECTED]>: > > > Hi, > > > Do you think the following program in function void > EventQueue::insert(Event > > > *event) is a bug? > > > > > > if (event->when() <= curr->when() && (event->when() < curr->when() || > > > event->priority() <= curr->priority())) > > > break; > > > > > > I think it should be the following: > > > > > > if (event->when() < curr->when() || (event->when() = curr->when() && > > > event->priority() <= curr->priority())) > > > break; > > > > > > > > > ________________________________ > > > > > > 快来用音乐为奥运加油 > > > 得奥运会、演唱会门票 > > > _______________________________________________ > > > m5-users mailing list > > > [email protected] > > > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > > > > > ------------------------------ > Get news, entertainment and everything you care about at Live.com. Check > it out! <http://www.live.com/getstarted.aspx> > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
