Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.arch Subject: taken -vs- untaken branches Message-ID: <496@cresswell.quintus.UUCP> Date: 25 Dec 87 01:17:40 GMT Organization: Quintus Computer Systems, Mountain View, CA Lines: 30 I thought that taken branches were always more costly than untaken branches, so that one should try to arrange branches so that the not-taken case was the commonest. There were some messages in this group a while back which seems to suggest that in some newer RISCs this was no longer the case. Would someone who understands such matters care to explain? It would also be interesting to see a comparison of - branch taken cache (processor keeps a cache of instructions and predicts that they will/won't be taken if they were/weren't the last time) - compiler-assigned fixed branch prediction bits - guessing that backward branches will be taken and forward ones won't Background: we have some code where a lot of time is going into a few fairly short loops L: b L ; usually taken and it would be fairly easy to unroll them a couple of times: L: b X ; usually NOT taken b X ; usually NOT taken b L ; usually taken X: but if non-taken branches are more costly than taken ones this would be a bad idea, so it would be good to have some idea of on which machines it would be a good idea and on which it wouldn't.