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! <http://www.live.com/getstarted.aspx>
>
> _______________________________________________
> 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

Reply via email to