Article View: comp.arch
Article #1726Re: delayed branch
From: Glenn Mackintosh
Date: Wed, 02 Aug 1989 20:01
Date: Wed, 02 Aug 1989 20:01
25 lines
1646 bytes
1646 bytes
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
Technical Details
Message-ID:
<1989Aug2.160111.9324@jarvis.csri.toronto.edu>Path:
arc1-ca.pugleaf.net!utzoo!attcan!utgpu!jarvis.csri.toronto.edu!csri.toronto.edu!glennReferences:
<2246@taux01.UUCP> <1462@l.cc.purdue.edu> <26139@shemp.CS.UCLA.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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