[fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

[Sven Barth]

Am 28.04.2018 um 10:11 schrieb Thorsten Engler:
>
> Oops, small mistake caused by last minute change (I replaced rol with 
> shl): it needs to be shr (or ror or rol, they all perform about the 
> same on my cpu).
>
> And in case anyone wonders, the first cmp and branch returns 0 for 
> numbers that would cause an integer overflow, and the 2^nd cmp and 
> branch skips  the whole thing if the input is between -1 and 1 (so it 
> already is just a fraction).
>
> Also, at least on my CPU (AMD Phenom II X6, so not exactly the newest) 
> the effect of code alignment on performance is huge. (It affects the 
> branch predictor I think.) I’m not sure what the best alignment is for 
> all CPUs.
>
> .align 16 forces alignment of the function entry point to a multiple 
> of 16. If I add between 0 and 3 nops at the start of the function, the 
> timings for calling it 10 million times are:
>
The question is whether we should really return 0 for numbers that would 
cause an integer overflow as from the user's perspective of this 
function integers aren't involved at all (after all one passes in a 
floating point value and receives one).
Maybe it would be better if we'd provide an optimized Int() function and 
Frac() then simply stays "d - Int(d)".

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180428/329ad4cf/attachment.html>