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
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
aertner
> Sent: Saturday, 28 April 2018 19:18
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows
> x86_64
>
> On Sat, 28 Apr 2018 10:55:10 +0200
> Sven Barth via fpc-devel wrote:
>
> >[...]
> > The questio
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
rdacht *** Re: [fpc-devel] Broken frac function in
FPC3.1.1 / Windows x86_64
Bart mailto:bartjun...@gmail.com> > schrieb am Fr., 27.
Apr. 2018, 13:42:
On Wed, Apr 25, 2018 at 11:04 AM, mailto:i...@wolfgang-ehrhardt.de> > wrote:
> If you compile and run this 64-bit program on Wi
On Sat, 28 Apr 2018 02:48:14 +1000
"Thorsten Engler" wrote:
> For what it’s worth, Delphi simply decided to give up on doing it correctly
> and silently fail if the double is too large to fit in an Int64.
>[...]
> WriteLn(Frac(1e15+0.5));
>
> WriteLn(Frac(1e16+0.5));
>
> When executed in 32bit
Thorsten Engler schrieb am Fr., 27. Apr. 2018,
18:48:
> For what it’s worth, Delphi simply decided to give up on doing it
> correctly and silently fail if the double is too large to fit in an Int64.
>
>
>
> WriteLn(Frac(1e15+0.5));
>
> WriteLn(Frac(1e16+0.5));
>
>
>
> When executed in 32bit code,
For what it’s worth, Delphi simply decided to give up on doing it correctly and
silently fail if the double is too large to fit in an Int64.
WriteLn(Frac(1e15+0.5));
WriteLn(Frac(1e16+0.5));
When executed in 32bit code, returns:
5.00E-0001
5.00E-0001
And w
Bart schrieb am Fr., 27. Apr. 2018, 13:42:
> On Wed, Apr 25, 2018 at 11:04 AM, wrote:
>
> > If you compile and run this 64-bit program on Win 64 you get a crash
>
> And AFAICS your analysis of the cause (see bugtracker) is correct as well.
>
> function fpc_frac_real(d: ValReal) : ValReal;compil
On Wed, Apr 25, 2018 at 11:04 AM, wrote:
> If you compile and run this 64-bit program on Win 64 you get a crash
And AFAICS your analysis of the cause (see bugtracker) is correct as well.
function fpc_frac_real(d: ValReal) : ValReal;compilerproc; assembler;
nostackframe;
asm
cvttsd2si %xm
On Wed, Apr 25, 2018 at 11:04 AM, wrote:
> If you compile and run this 64-bit program on Win 64 you get a crash
Confirmed on Win64 with r37885 .
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailma
> Note that "reporter" means that somebody's not a manager of the bug
> tracker. The designation covers a lot of people who are regular
> contributors to- and testers of- the core FPC code, and it's
> probably unfair for somebody to accuse one of them of trolling
> without considering that.
"repor
On 27/04/18 06:45, Thorsten Engler wrote:
But the only responses are by a reporter named Thaddy de Koning,> which are for
me totally useless and IMO he did miss the point.It's not the first time the
person has been less than helpful...
After looking through other issues he has commented on, I
On 25.04.2018 11:04, i...@wolfgang-ehrhardt.de wrote:
But the only responses are by a reporter named Thaddy de Koning, which
are for me totally useless and IMO he did miss the point.
Welcome to the FPC bug tracker! ;)
Ondrej
___
fpc-devel maillist -
> But the only responses are by a reporter named Thaddy de Koning,
> which are for me totally useless and IMO he did miss the point.
It's not the first time the person has been less than helpful...
After looking through other issues he has commented on, I don't think he has
contributed anything b
If you compile and run this 64-bit program on Win 64 you get a crash
program tfrac;
var
x,y: double;
begin
x := 1e20;
writeln('x=',x);
y := frac(x);
writeln('frac(x)=',y);
end.
D:\Work\DAMath>D:\FPC311\bin\i386-win32\ppcrossx64.exe tfrac.pas
Free Pascal Compiler version 3.1.1-r20:38794
21 matches
Mail list logo