Florian Klaempfl wrote:
Am 19.04.2011 15:18, schrieb Marco van de Voort:
You'll need to runtime test for SSE3 though. Since the first
generation of
athlon64's (clawhammer and friends, socket 751 or so) doesn't have SSE3.
For such a relatively expensive operations, one runtime check per
Am 21.04.2011 21:14, schrieb Micha Nelissen:
Florian Klaempfl wrote:
Am 19.04.2011 15:18, schrieb Marco van de Voort:
You'll need to runtime test for SSE3 though. Since the first
generation of
athlon64's (clawhammer and friends, socket 751 or so) doesn't have SSE3.
For such a relatively
Am 20.04.2011 00:05, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
think it's a matter of bad algorithms.
Some algorithms convert faster with
Am 20.04.2011 11:26, schrieb Michael Schnell:
On 04/19/2011 03:14 PM, Florian Klaempfl wrote:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
think it's a matter of bad algorithms.
Doing things like
Florian Klämpfl schrieb:
Am 20.04.2011 00:05, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
think it's a matter of bad algorithms.
Some
Am 20.04.2011 15:04, schrieb Hans-Peter Diettrich:
Florian Klämpfl schrieb:
Am 20.04.2011 00:05, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
Op Wed, 20 Apr 2011, schreef Hans-Peter Diettrich:
Of course there exists no general rule, it depends on the concrete purpose of
a calculation, which algorithm, precision and type (BCD, fixed point...)
yields the best results. But there also exists no reason why a coder should
be prevented
2011/4/19 Nikolai Zhubr n-a-zh...@yandex.ru:
Now, with the
introduction of 64-bit processors IIRC AMD took care of this problem by
providing some means to execute floating-point operations without the need
for traditional FPU register space, thus allowing to avoid the need to
save/restore FPU
On 19 Apr 2011, at 11:43, Alexander Klenin wrote:
2011/4/19 Nikolai Zhubr n-a-zh...@yandex.ru:
Now, with the
introduction of 64-bit processors IIRC AMD took care of this
problem by
providing some means to execute floating-point operations without
the need
for traditional FPU register
19.04.2011 13:43, Alexander Klenin:
2011/4/19 Nikolai Zhubrn-a-zh...@yandex.ru:
Now, with the
introduction of 64-bit processors IIRC AMD took care of this problem by
providing some means to execute floating-point operations without the need
for traditional FPU register space, thus allowing to
Am 19.04.2011 12:12, schrieb Daniël Mantione:
Op Tue, 19 Apr 2011, schreef Nikolai Zhubr:
ms (supposedly) decided to just not preserve FPU/MMX state between
64-bit processes.
MS does preserve FPU states between processes. You can use the x87 on
Windows, nothing prevents you from doing
19.04.2011 14:12, Daniël Mantione:
MS does preserve FPU states between processes. You can use the x87 on
Windows, nothing prevents you from doing so. Maybe the calling
Yes it does for 32-bit processes on win64, guaranteed.
But do you have any evidence (tests/documents/links) proving it also
Nikolai Zhubr schrieb:
Originally MS spread info it wouldn't work at all under Windows, but
that proved to be false,
the FPU works technically. Now MS just states it is unsupported.
And deprecated:
http://msdn.microsoft.com/en-us/library/ee418798(VS.85).aspx#Porting_to_64bit
Thanks. I
Op Tue, 19 Apr 2011, schreef Nikolai Zhubr:
19.04.2011 14:12, Daniël Mantione:
MS does preserve FPU states between processes. You can use the x87 on
Windows, nothing prevents you from doing so. Maybe the calling
Yes it does for 32-bit processes on win64, guaranteed.
But do you have any
Op Tue, 19 Apr 2011, schreef Florian Klämpfl:
It's just that the documentation tells you not to use the x87.
Yes, because it's strange programming model should be really dropped.
Agree, but the 80 bit support makes some people want to use it. And that
will stay this way until CPU
Am 19.04.2011 12:27, schrieb Daniël Mantione:
Op Tue, 19 Apr 2011, schreef Florian Klämpfl:
It's just that the documentation tells you not to use the x87.
Yes, because it's strange programming model should be really dropped.
Agree, but the 80 bit support makes some people want to use it.
In our previous episode, Dani?l Mantione said:
By the way, recent GCC versions calculate the goniometric functions in
software using SSE3, and I checked that this is indeed slightly faster
than the x87. So we can get rid to the x87 stuff, should we want.
You'll need to runtime test for
Am 19.04.2011 15:18, schrieb Marco van de Voort:
In our previous episode, Dani?l Mantione said:
By the way, recent GCC versions calculate the goniometric functions in
software using SSE3, and I checked that this is indeed slightly faster
than the x87. So we can get rid to the x87 stuff, should
Florian Klaempfl schrieb:
Using extended typically hides only bad numerical algorithms. There
might be some corner cases where extended is usefull but I general I
think it's a matter of bad algorithms.
Some algorithms convert faster with increased accuracy.
DoDi
Op Mon, 18 Apr 2011, schreef Hans-Peter Diettrich:
Sven Barth schrieb:
On Windows 64-bit you must not use the x87 FPU, because Microsoft wants it
so.
Can you be a bit more concrete?
Originally MS spread info it wouldn't work at all under Windows, but that
proved to be false, the FPU
On 18 Apr 2011, at 10:13, Daniël Mantione wrote:
Originally MS spread info it wouldn't work at all under Windows, but
that proved to be false,
the FPU works technically. Now MS just states it is unsupported.
And deprecated:
Jonas Maebe schrieb:
On 18 Apr 2011, at 10:13, Daniël Mantione wrote:
Originally MS spread info it wouldn't work at all under Windows, but
that proved to be false,
the FPU works technically. Now MS just states it is unsupported.
And deprecated:
Some time ago I've heard a rumor that the Extended type is not supported
by x86_64 targets. But AFAIK the x87 FPU continues to exist in 64 bit
machines, and is still accessible by the well known coprocessor
instruction set.
So what's the current state of floating point types in FPC?
DoDi
On 17.04.2011 19:30, Hans-Peter Diettrich wrote:
Some time ago I've heard a rumor that the Extended type is not supported
by x86_64 targets. But AFAIK the x87 FPU continues to exist in 64 bit
machines, and is still accessible by the well known coprocessor
instruction set.
So what's the current
Op Sun, 17 Apr 2011, schreef Sven Barth:
On Windows 64-bit you must not use the x87 FPU, because Microsoft wants it
so. Thus on Win64 Extended=Double.
On other x86_64 based operating systems the state might be different.
You can use the x87 on Linux. Don't know for FreeBSD, but I expect
Sven Barth schrieb:
On Windows 64-bit you must not use the x87 FPU, because Microsoft wants
it so.
Can you be a bit more concrete?
DoDi
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
26 matches
Mail list logo
