I’ve only tested it in Delphi, so you’ll have to convert it to the right syntax
for fpc, but either of these should do:
function Frac1(const X: Double): Double;
asm
.align 16
.noframe
movq rdx, xmm0
shl rdx, 32
and edx, $7FF0
cmp edx, $4330
On Fri, Apr 27, 2018 at 11:05 PM, Sven Barth via fpc-devel
wrote:
> Nope, fixed in r38860. :)
That's quick.
Thanks.
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Am 27.04.2018 um 22:48 schrieb Bart:
On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel
wrote:
It's a bug due to refactoring. I'll commit the fix once I got to run the
testsuite.
So, I need not file a bugreport then?
Nope, fixed in r38860. :)
On Fri, Apr 27, 2018 at 5:49 PM, Sven Barth via fpc-devel
wrote:
> It's a bug due to refactoring. I'll commit the fix once I got to run the
> testsuite.
So, I need not file a bugreport then?
Bart
___
fpc-devel maillist
Yeah, I realized that myself and made a post about that a few minutes ago which
seems to have crossed ways with yours...
I was just projecting my annoyance about the lack of precision when being
forced to do math in double instead of extended...
> -Original Message-
> From: fpc-devel
Actually, that test is wrong, because the 32bit code will use Extended float
literals instead of Double. If you force it to use double in 32bit you get the
same result.
If you want to use SSE instructions, you will need to add additional checks to
see if the value will fit into an integer
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));
>
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));
>
>
>
>
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
Thorsten Engler schrieb am Fr., 27. Apr. 2018,
17:47:
> > That's true for i386. But on x86_64 cvt(t)sd2si instuctions can
> > deal with int64 range, if destination register is a 64-bit one.
>
> You are still going to be at least 960-bit short...
>
I've disabled the SSE
Bart schrieb am Do., 26. Apr. 2018, 19:29:
> Is this a bug, or was it changed by design?
>
It's a bug due to refactoring. I'll commit the fix once I got to run the
testsuite.
Regards,
Sven
>
___
fpc-devel maillist -
> That's true for i386. But on x86_64 cvt(t)sd2si instuctions can
> deal with int64 range, if destination register is a 64-bit one.
You are still going to be at least 960-bit short...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Sat, 28 Apr 2018 00:09:12 +1000
"Thorsten Engler" wrote:
> Highest integer that fits in a Int64:
> 9223372036854775808
> 1e20:
> 1
>
> Your Int is overflowing.
>
> You can’t implement Frac by going through an Integer, that will never work.
It
27.04.2018 17:14, Sven Barth via fpc-devel wrote:
Thorsten Engler > schrieb am Fr., 27. Apr.
2018, 16:09:
Highest integer that fits in a Int64:
9223372036854775808
1e20:
1
__ __
Thorsten Engler schrieb am Fr., 27. Apr. 2018,
16:09:
> Highest integer that fits in a Int64:
>
> 9223372036854775808
>
> 1e20:
>
> 1
>
>
>
> Your Int is overflowing.
>
>
>
> You can’t implement Frac by going through an Integer, that will never
>
Highest integer that fits in a Int64:
9223372036854775808
1e20:
1
Your Int is overflowing.
You can’t implement Frac by going through an Integer, that will never work.
Except if you have an integer that can hold 1.8E308 (which would be a 1024 bit
integer, or
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.
>
>
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;
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
> 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.
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
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
24 matches
Mail list logo