Am 29.05.2018 um 21:48 schrieb J. Gareth Moreton: > That seems fair. Thank you for your > answer. I'm still learning about the > nuances of branch prediction and the like.
Do be honest, I never investigated this particular case in detail, but years I ago we just decided based on the reasons I mentioned. > > On Tue 29/05/18 21:27 , Florian Klämpfl > [email protected] sent: >> Am 28.05.2018 um 01:55 schrieb J. Gareth > Moreton: >> >>> >> >>> In this case, the ".balign" hint adds >> 2 bytes to pad the loop. However, my > question is this... why >>> does it immediately jump to the end of > the loop >> to check the condition (which is very > likely to be >>> true on the first iteration), only to > jump to >> the beginning again? >> >> >> Several reasons: >> >> - it is not that easy to find a > heuristics when the condition should be >> checked twice >> - two conditional jumps waste an extra > branch prediction table entry >> >> - bigger code, higher cache usage >> >> >> >> Weigthing these reasons against the > little overhead of an extra >> unconditional jump, we decided to >> use the currently used code generation > strategy. >> >> > __________________________________________ > _____ >> >> fpc-devel maillist - fpc- > [email protected] >> http://lists.freepascal.org/cgi- > bin/mailman/listinfo/fpc-devel >> >> >> >> > > _______________________________________________ > fpc-devel maillist - [email protected] > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
