As an extra point, removing the 'skip' check (i.e. cmp ax, $3FE0, jbe
@@skip) removes 6 bytes from the code size and shaves about 2 to 3
nanoseconds off the execution time in most cases, and it could be argued
that it's worth going for the 'no skip' version because using Frac on a
value of x where
I've done some speed and accuracy comparisons between our respective Frac
functions. Initially, my "SafeFrac" was marginally faster than
"FracDoSkip", but I managed to optimise Thorsten's routine a little bit
into the following:
function FracSkip2(const X: ValReal): ValReal; assembler; nostackf
If I may add a possible solution, would code akin to the following fix the
problems? (Pray that the mail list formatting doesn't mess it all up!)
{$WARN 7121 off : Check size of memory operand "$1: memory-operand-size is
$2 bits, but expected [$3 bits]"}
{$ASMMODE Intel}
const
MAX_D
> -Original Message-
> From: fpc-devel On Behalf
> Of Florian Klämpfl
> So something like
>
> cmp edx, $4330
> jge @@zero
> cmp edx, $3FE0
> .align 16
> jbe @@skip
>
> might be much better.
That ended up making things worse in some cases.
Here
On 04/28/2018 09:33 AM, Thorsten Engler wrote:
I've attached the source (I'm using Delphi 10.2.3, 64bit to compile it) in
case anyone wants to try it out on different cpus and with different
alignments (change the {$CODEALIGN 1} and add nops to the XXX1 .. XXX8
procedures to finetune alignment).
Am 28.04.2018 um 15:33 schrieb Thorsten Engler:
> procedure XXX1;
> asm
> .noframe
> nop
> nop // added this
> end;
I did not look at the code in detail but I suspect this is caused by the two
branches:
cmp edx, $4330
jge @@zero
cmp edx, $3FE0
jbe @@s
> -Original Message-
> From: fpc-devel On Behalf
> Of wkitt...@windstream.net
> > Code address:
> > Frac1: 00536430 (48)
> > Frac2: 00536480 (0)
> > Frac3: 005364D0 (80)
> > Frac4: 00536520 (32)
> > Frac5: 00536570 (112)
> > Frac6: 005365C0 (
On 04/28/2018 07:01 AM, Thorsten Engler wrote:
The effects of code alignment beyond a granularity of 16 on such short code is
interesting:
Code address:
Frac1: 00536430 (48)
Frac2: 00536480 (0)
Frac3: 005364D0 (80)
Frac4: 00536520 (32)
Frac5: 00536570 (11
> -Original Message-
> From: fpc-devel On Behalf
> Of Sven Barth via fpc-devel
> Thorsten, do you have tests that could go with the new
> Frac() implementation? Something simply that checks the results and
> does a Halt() if something is wrong would be sufficent.
I was using the followin
Am 28.04.2018 um 11:28 schrieb Thorsten Engler:
Basically that.
For doubles that don't fit into an Int64, any fraction is beyond the
significant number of digits that the double can store anyway, so 0 is the
valid and correct result for Frac in that case.
Since a float only stores the highe
Basically that.
For doubles that don't fit into an Int64, any fraction is beyond the
significant number of digits that the double can store anyway, so 0 is the
valid and correct result for Frac in that case.
> -Original Message-
> From: fpc-devel On Behalf
> Of Mattias Gaertner
> Sent:
On Sat, 28 Apr 2018 10:55:10 +0200
Sven Barth via fpc-devel wrote:
>[...]
> 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
> floati
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 ca
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 2nd cmp and branc
14 matches
Mail list logo
