|Backward branches firstname.lastname@example.org (2003-12-14)|
|Re: Backward branches email@example.com (2003-12-20)|
|Re: Backward branches firstname.lastname@example.org (2003-12-21)|
|Re: Backward branches email@example.com (2004-01-02)|
|Re: Backward branches firstname.lastname@example.org (2004-01-09)|
|Re: Backward branches email@example.com (Jens Troeger) (2004-01-12)|
|Re: Backward branches Robert.Thorpe@antenova.com (Robert Thorpe) (2004-01-16)|
|Date:||2 Jan 2004 03:46:42 -0500|
|Posted-Date:||02 Jan 2004 03:46:42 EST|
firstname.lastname@example.org (Torben Ęgidius Mogensen) wrote in message news:03-12-109...
> email@example.com (kugan) writes:
> > I need to detect loops using H/W. I am wondering whether it is
> > possible to detect loops just by detecting backward branches. What
> > would be the approximate success rate for this scheme? What are the
> > other instances where backward branches will be used?
> Any loop (that hasn't been fully unrolled) will certainly involve a
> backwards branch at some point. Not all backwards branches are loops,
> though. If you reorder basic blocks, you can well have one branch of
> an if-then-else placed after the join-point, so you need a backwards
> jump to get to the join-point. Jumps to exception-handling code can
> also be backwards, but compilers would tend to make these forwards as
> some branch predictors assume backwards branches are taken (until they
> have gathered evidence to the contrary).
Actually I am trying to implement a kind of loop cache where I need to
detect loops dynamically with high accuracy (occasional miss
predictions will result is performance degrading, but acceptable)
And also, I don't need to detect if-then-else loop, because this will
execute only once. What I need to detect is "while loop", "for loop"
etc. As I said earlier, I can ignore exception, as it would happen
So, from what I understood from your reply, it should work (leaving
the exception) without any compiler assistance. Is it correct?
Return to the
Search the comp.compilers archives again.