It will be particularly important in multiprocessor simulation. Nate
2008/5/13 Steve Reinhardt <[EMAIL PROTECTED]>: > Great. It'd still be nice to have the property that all significant > ordering constraints are encoded via priorities so that FIFO vs LIFO is > irrelevant. > > Steve > > 2008/5/13 nathan binkert <[EMAIL PROTECTED]>: > > > > > I have a new tree based event queue that I've been using for several > > months. A side effect of the new design is that it's now FIFO. I'll > > get it committed when we get our source tree sorted out. > > > > Nate > > > > 2008/5/13 Steve Reinhardt <[EMAIL PROTECTED]>: > > > > > > > > > Thanks for bringing it up again... I will try and remember to get it > fixed. > > > > > > Steve > > > > > > > > > 2008/5/13 KE MENG <[EMAIL PROTECTED]>: > > > > > > > > > > > > Yes, I agree with that. > > > > > > > > > > > > > > > > ________________________________ > > > Date: Tue, 13 May 2008 10:02:12 -0700 > > > > From: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > To: [email protected] > > > > Subject: Re: [m5-users] a bug report > > > > > > > > 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! > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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! > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
