Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!csri.toronto.edu!glenn
From: glenn@csri.toronto.edu (Glenn Mackintosh)
Newsgroups: comp.arch
Subject: Re: delayed branch
Message-ID: <1989Aug2.160111.9324@jarvis.csri.toronto.edu>
Date: 2 Aug 89 20:01:11 GMT
References: <2246@taux01.UUCP> <1462@l.cc.purdue.edu> <26139@shemp.CS.UCLA.EDU>
Lines: 25

frazier@oahu.cs.ucla.edu (Greg Frazier) writes:
>There are two problems with filling delay slots.  The first is that
>branches occur on the order of every 3 to 5 instructions - that's
>a lot of slots to fill.  The second is that one often branches on
>a value immediately after calculating it (i++; if i > 5 ...).

Hmmm. That just made me think about something. Has anyone looked at taking
something like the above and having the compiler recognize that it could
rearrange things a bit in cases like this? For example the compiler could
change this to do a compare against 4 and move the increment into the delay
slot after the test. I have a feeling that a lot off loop code has this kind
of termination structure. If you just add/subtract some fixed number from
your loop control variable and then test to see if it has gone beyond a
fixed range then you could easily adjust the range so that the test could be
done first.

Has anybody done this kind of thing and if so how did it come out?

                    Glenn Mackintosh
                    Univ. of Toronto

CSNET/ARPA:   glenn@eecg.{toronto.edu,utoronto.ca}
CDNNET:       glenn@eecg.toronto.cdn
BITNET:       glenn@eecg.utoronto.bitnet (may not work from all sites)
UUCP:         uunet!utai!eecg!glenn