Jonas Maebe wrote:
On 02 Oct 2007, at 21:52, Daniël Mantione wrote:
Of course not, because the sizes of the floating point types is
defined by the IEEE 754 standard. On x86_64, you will have exactly the
same types as on i386: single (32-bit), double (64-bit) and extended
(80-bit).
Except for
Michael Schnell schrieb:
> Jonas Maebe wrote:
>>
>> On 02 Oct 2007, at 21:52, Daniël Mantione wrote:
>>
>>> Of course not, because the sizes of the floating point types is
>>> defined by the IEEE 754 standard. On x86_64, you will have exactly the
>>> same types as on i386: single (32-bit), double (
Michael Schnell schrieb:
>
>> In some Win64 beta MS disabled even the use of the FPU. Because this
>> went too far, MS marked the use of the FPU as deprecated.
>>
> OK, for a Beta this might be OK (and done supposedly due to the OS
> failing to manage the FPU registers correctly), but the final
Hi;
I have been trying to (re)compile via the current downloadable
fpc-2.2.0-0.src.rpm on a Fedora FC5 platform like this:
# rpmbuild --rebuild fpc-2.2.0-0.src.rpm .. and
# rpmbuild --rebuild --target i686-linux-fc5 fpc-2.2.0-0.src.rpm
My current fpc originates from the FC5 package fpc-2.0.
In some Win64 beta MS disabled even the use of the FPU. Because this
went too far, MS marked the use of the FPU as deprecated.
OK, for a Beta this might be OK (and done supposedly due to the OS
failing to manage the FPU registers correctly), but the final product
needs to support all the CP
It is supported but deprecated because x87 fpu simply gives compilers a
headache.
Are there new floating point instruction in the 64 bit instruction set
and the old instructions are still there but not necessary to access the
floating point hardware ?
If so, why would any 64 bit compiler use
Op Thu, 4 Oct 2007, schreef Michael Schnell:
>
> > It is supported but deprecated because x87 fpu simply gives compilers a
> > headache.
> Are there new floating point instruction in the 64 bit instruction set and the
> old instructions are still there but not necessary to access the floating
>
On 04 Oct 2007, at 12:36, Daniël Mantione wrote:
Still, we're planning to support the extended on all platforms by
means of
softfloat.
I don't think it would be a good idea to map the extended type to 80
bit soft float on platforms that don't support 80 bit fpu
calculations in hardware.
You have to set the path to the new fpc-sources. That could be difficult
since they are extracted to a temporary place. As a workaround, extract
the sources somewhere and do this before you start the build:
export FPC_DIR=path/to/fpcbuild/fpcsrc
btw: I'll update the fedora rpm's this weekend.
Jo
On 04 Oct 2007, at 13:00, Daniël Mantione wrote:
I don't think it would be a good idea to map the extended type to
80 bit soft
float on platforms that don't support 80 bit fpu calculations in
hardware.
Many programs use "extended" by default without actually requiring
80 bit
precision, and
Michael Schnell schrieb:
>
>> The x86 has nowadays 2 fpu's: the x87 and SSE. SSE does single and (if
>> SSE2 present) double precision, the x87 single double and extended.
>> On x86_64 the calling conventions have been designed to use the SSE
>> registers.
>>
> This might make sens if you want
On 04 Oct 2007, at 13:13, Daniël Mantione wrote:
Op Thu, 4 Oct 2007, schreef Jonas Maebe:
It won't keep it working but rather break it, since currently
writing an
extended to file on virtually all platforms writes a double to the
file.
The majority of code has not been ported to non-x86.
It's probably better to directly introduce a longdouble type with
longdouble (128 bit) semantics on all platforms. I don't think that
emulating the almost nowhere supported 80 bit type does much good.
Is 128 bit supported by any hardware ? 80 bit is and it's an IEEE
standard format. So I can't
Op Thu, 4 Oct 2007, schreef Jonas Maebe:
> It won't keep it working but rather break it, since currently writing an
> extended to file on virtually all platforms writes a double to the file.
The majority of code has not been ported to non-x86. To obtain a healthy
base of compilable code, non-x
The x86 has nowadays 2 fpu's: the x87 and SSE. SSE does single and
(if SSE2 present) double precision, the x87 single double and extended.
On x86_64 the calling conventions have been designed to use the SSE
registers.
This might make sens if you want to use both FPUs at the same time. but
p
Op Thu, 4 Oct 2007, schreef Jonas Maebe:
>
> On 04 Oct 2007, at 12:36, Daniël Mantione wrote:
>
> > Still, we're planning to support the extended on all platforms by means
> > of
> > softfloat.
>
> I don't think it would be a good idea to map the extended type to 80 bit soft
> float on platfo
On 04 Oct 2007, at 13:24, Michael Schnell wrote:
It's probably better to directly introduce a longdouble type with
longdouble (128 bit) semantics on all platforms. I don't think
that emulating the almost nowhere supported 80 bit type does much
good.
Is 128 bit supported by any hardware ?
Michael Schnell schrieb:
>
>> No. This was MMX. SSE is always separate.
>>
> How does an old OS that does not know about SSE do the task switch ?
It doesn't. You can't use SSE on e.g. unpatched Win95 or WinNT.
>
>> No, it's cutting of old hindering stuff.
>>
> If doing Mathematical calcul
So I can't imagine why it is "nowhere supported"
Because the x86 is pretty much the only one to support it in hardware.
Supposedly this counts for 90% of the FPUs produced in 2007...
OK. things do change.
-Michael
___
fpc-devel maillist - fpc-d
Op Thu, 4 Oct 2007, schreef Florian Klaempfl:
> > If doing Mathematical calculations it of course is best to use the
> > format that offers the best accuracy when it's not slower. AFAIK the FPU
> > is not slower when doing 80 bit than when doing 64 bit (of course
> > loading/storing the values m
Always storing the FPU simply increases task switch time. Further, SSE
is simply faster with 64 bit because of the easier to use register file
and because more registers are available on 64 Bit CPUs.
That does make sense !
Does the FPU share these 64 bit registers with the 64 bit integer unit
No. This was MMX. SSE is always separate.
How does an old OS that does not know about SSE do the task switch ?
No, it's cutting of old hindering stuff.
If doing Mathematical calculations it of course is best to use the
format that offers the best accuracy when it's not slower. AFAIK th
Jonas Maebe schrieb:
>
> On 04 Oct 2007, at 13:24, Michael Schnell wrote:
>
>>> It's probably better to directly introduce a longdouble type with
>>> longdouble (128 bit) semantics on all platforms. I don't think that
>>> emulating the almost nowhere supported 80 bit type does much good.
>> Is 12
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Actually this is the whole core of the matter: Microsoft's
> developers though they could save the task switch time by not
> storing the fpu.
>
> However, later they discovered it was a huge security leak,
> and added the fpu store code.
For wh
Hi,
On unix TProcess.Terminate will send a TERM signal, if this succeeds it
will poll if it exited, and immediately send a KILL signal if not. Isn't
this a bit rigorous ? It may not have had a change to run even, let
alone terminate properly.
Also, it calls GetExitStatus.
Perhaps there should be
25 matches
Mail list logo
