Yes, I agree with that.
Date: Tue, 13 May 2008 10:02:12 -0700From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: Re: [m5-users] a bug reportI 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())) toif (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 [EMAIL
PROTECTED]://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
