-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
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
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
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
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
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
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 ?
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
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
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: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
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
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
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.
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
>
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
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
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
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 (
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
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 Win64, where we onl
Op Tue, 2 Oct 2007, schreef Alain Michaud:
> Hi,
>
> in the 32 bits systems, the 'double' type is 64 bits long and the
> 'extended' type is 80 bits long. Are the 64 bits systems better than
> that ?
Of course not, because the sizes of the floating point types is
defined by the IEEE 754 st
Hi,
in the 32 bits systems, the 'double' type is 64 bits long and the
'extended' type is 80 bits long. Are the 64 bits systems better than
that ?
Thank you
Alain
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepasca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Oops ?!?! I supposed that using the much greater count of registers
> in 64 bit mode could speed up any kind of software. I suppose that
> the experts _are _working on that, though.
Registers are only so useful. I have a very nice example program wh
On 02/10/2007, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
> AMD64 : original (AMD)name of x86_64
> EMT64 : Intel name of x86_64
> x86_64: neutral (and GNU) name of x86_64.
>
> IA-64 is of course Itanium and a really different architecture.
Ah, thanks Marco!
Regards,
- Graeme -
__
[ Charset ISO-8859-1 unsupported, converting... ]
> On 02/10/2007, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> > IA-64: no, IA-64 is the architecture used by the Itanium Or do you mean
> > x86-64/AMD64/EMT64?
>
> Sorry if this sounds stupid, but I've never dabbed into the 64bit
> world. What are
Michael Schnell schrieb:
> Oops ?!?! I supposed that using the much greater count of registers in
> 64 bit mode could speed up any kind of software.
No. 64 Bit causes also more memory traffic because everything being an
address has the double size. So it depends on the application if 64 bit
is fa
On 02/10/2007, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> IA-64: no, IA-64 is the architecture used by the Itanium Or do you mean
> x86-64/AMD64/EMT64?
Sorry if this sounds stupid, but I've never dabbed into the 64bit
world. What are all those XXX64 platforms / architectures?
Architectures from
x86-64/AMD64/EMT64?
Right ! Sorry for the silly notation.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
FPC can create IA32 and AMD64 code, not IA64 code.
That is what I meant by IA 32/64. I did not suppose it can create
Inatium code :-) .
A 64-bit OS is necessary.
I suppose this is because the API calls generated are 64 bit. Correct ?
Does / can a 64 Bit FPC generated program include
Michael Schnell schrieb:
> Hi experts ?
>
> I suppose that FPC can create 64 bit (IA-32/64) code.
IA-32: yes, it's plain i386+ code
IA-64: no, IA-64 is the architecture used by the Itanium Or do you mean
x86-64/AMD64/EMT64?
Is that correct ?
> Linux and/or Windows ?
>
> Can this be done by "c
Op Tue, 2 Oct 2007, schreef Michael Schnell:
> Hi experts ?
>
> I suppose that FPC can create 64 bit (IA-32/64) code. Is that correct ? Linux
> and/or Windows ?
FPC can create IA32 and AMD64 code, not IA64 node.
> Can this be done by "cross"-compiling on a 32 Bit PC ? Linux and/or Windows ?
Hi experts ?
I suppose that FPC can create 64 bit (IA-32/64) code. Is that correct ?
Linux and/or Windows ?
Can this be done by "cross"-compiling on a 32 Bit PC ? Linux and/or
Windows ?
Does a 64 Bit FPC generated program need to run on a 64 Bit OS ? (Linux
and/or Windows ?) or can it jus
35 matches
Mail list logo
