4 ms·
Then you just calculate them all. If Branch A is taken ... total X clock-cycles. If Branch B is taken ... total X clock-cycles. If Branch C is taken ... tota
by pepoluan 5y ago
Then you just calculate them all.
If Branch A is taken ... total X clock-cycles.
If Branch B is taken ... total X clock-cycles.
If Branch C is taken ... total X clock-cycles.
And so on. And then make sure that the "longest" branch fits into the clock-cycle budget.
- kqr 5y agoWere games at this point of low enough complexity that the combinatorial explosion of branches could be contained and reasoned about by humans? Or did you have software doing this?
- Jensson 5y agoThere is no such thing as combinatorial explosion here, just take the longest branch every time.
- kqr 5y agoBut this means if you have a situation like if (a) { ... } ... if (b) { ... } Where the branches are long, and b = !a, you significantly overestimate the amount of code. I guess that was considered good enough, then?
- mjul 5y agoYou just need your code to finish before the next frame. Then you wait and start the next cycle when you receive the interrupt from the start of the next frame from your graphics hardware. Of course once you start writing for heterogeneous hardware like PCs with very different performance between models, you may use adaptive approaches to use all the available resources rather than just providing the most basic experience for everyone.
- SavantIdiot 5y agoYes. However, this is part of the reason why you always try to avoid performing if/then in critical loops. Obviously the index counter cannot be hoisted, but if you are doing 1000 iterations, 2-bit Yeh prediction (which was common at the time) can be amortized. Later CPU architectures speculatively executed and then re-executed instructions that were incorrect due to branching, and VLIW allowed you to "shut off" instructions in a loop rather than have to predict.