Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59619 > unrolled thread

Does each core of 8-core Intel processor has an independent floating X87 unit?

Back to article view | Back to comp.lang.c

Contents

  Does each core of 8-core Intel processor has an independent floating X87 unit? Weng Tianxiang <wtxwtx@gmail.com> - 2015-04-05 06:50 -0700
    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Noob <root@127.0.0.1> - 2015-04-05 17:17 +0200
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 17:35 +0200
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:21 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 18:40 +0200
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:56 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 10:08 -0700
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 13:17 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 10:10 +0200
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 10:26 -0500
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 23:40 +0200
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Bartc <bc@freeuk.com> - 2015-04-07 23:06 +0100
                          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-08 01:23 +0200
                            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 23:15 -0500
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 20:16 -0500
                          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-08 09:27 +0200
                            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-08 09:44 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 19:37 +0200
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 18:50 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-05 22:29 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 23:09 -0500
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 01:54 -0500
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 07:44 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 10:16 +0200
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-07 03:32 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 12:48 +0200
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:57 +0100
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 13:33 +0200
                        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-07 15:21 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 17:15 +0000
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Tim Prince <tprince@computer.org> - 2015-04-07 14:21 -0400
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:08 -0700
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 15:27 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Noob <root@127.0.0.1> - 2015-04-05 19:04 +0200
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 19:38 +0200
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 10:46 -0700
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:12 -0700
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 09:51 -0700
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 12:18 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? jacobnavia <jacob@jacob.remcomp.fr> - 2015-04-06 01:30 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 19:27 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? christian.bau@cbau.wanadoo.co.uk - 2015-04-07 23:58 -0700
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-08 08:08 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-06 03:36 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 10:27 +0200
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-07 10:39 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? christian.bau@cbau.wanadoo.co.uk - 2015-04-07 23:47 -0700
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:04 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-05 18:20 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-05 11:43 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-05 20:28 +0000
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-05 14:46 -0700
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? fir <profesor.fir@gmail.com> - 2015-04-05 15:01 -0700
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Keith Thompson <kst-u@mib.org> - 2015-04-05 13:17 -0700
    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Paul <nospam@needed.com> - 2015-04-05 14:31 -0400
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 11:01 +0200
    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-05 22:34 -0500
      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Weng Tianxiang <wtxwtx@gmail.com> - 2015-04-05 23:39 -0700
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 02:06 -0500
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 08:57 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 12:38 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 16:30 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-06 17:10 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Ian Collins <ian-news@hotmail.com> - 2015-04-07 10:16 +1200
                    Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Melzzzzz <mel@zzzzz.com> - 2015-04-07 02:23 +0200
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 17:36 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 17:41 -0500
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 20:09 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Richard Damon <Richard@Damon-Family.org> - 2015-04-06 22:44 -0400
                      Re: Does each core of 8-core Intel processor has an independent floating X87 unit? David Brown <david.brown@hesbynett.no> - 2015-04-07 11:11 +0200
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Weng Tianxiang <wtxwtx@gmail.com> - 2015-04-06 08:04 -0700
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 12:43 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Paul <nospam@needed.com> - 2015-04-06 14:52 -0400
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? BGB <cr88192@hotmail.com> - 2015-04-06 17:09 -0500
        Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Paul <nospam@needed.com> - 2015-04-06 11:11 -0400
          Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-06 12:47 -0500
            Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-06 17:15 -0500
              Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Robert Wessel <robertwessel2@yahoo.com> - 2015-04-07 03:41 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Ian Collins <ian-news@hotmail.com> - 2015-04-07 21:19 +1200
                  Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-07 10:37 -0500
                    Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Tim Prince <tprince@computer.org> - 2015-04-07 12:13 -0400
                      Re: Does each core of 8-core Intel processor has an independent floating   X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-09 12:34 -0500
                Re: Does each core of 8-core Intel processor has an independent floating X87 unit? Stephen Sprunk <stephen@sprunk.org> - 2015-04-07 10:48 -0500

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#59677

On 4/5/2015 10:29 PM, Robert Wessel wrote:
> On Sun, 05 Apr 2015 18:50:54 -0500, BGB <cr88192@hotmail.com> wrote:
>
>> On 4/5/2015 12:37 PM, Melzzzzz wrote:
>>> On Sun, 05 Apr 2015 11:56:13 -0500
>>> BGB <cr88192@hotmail.com> wrote:
>>>
>>>> On 4/5/2015 11:40 AM, Melzzzzz wrote:
>>>>> On Sun, 05 Apr 2015 11:21:52 -0500
>>>>> BGB <cr88192@hotmail.com> wrote:
>>>>>
>>>>>> On 4/5/2015 10:35 AM, Melzzzzz wrote:
>>>>>>> On Sun, 05 Apr 2015 17:17:42 +0200
>>>>>>> Noob <root@127.0.0.1> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> And x87 is obsolete.
>>>>>>>>
>>>>>>>
>>>>>>> Who said that?
>>>>>>>
>>>>>>
>>>>>> AMD mostly.
>>>>>>
>>>>>>
>>>>>> when they created the x86-64 / AMD64 ISA, IIRC they also classified
>>>>>> x87 (among other things) as a deprecated feature. the main existing
>>>>>> 64-bit ABIs (SysV/AMD64 and Win64) also regard x87 as deprecated
>>>>>> AFAIK.
>>>>>>
>>>>>> I don't know if Intel has said anything on the matter, but either
>>>>>> way, x87 hasn't really been a big thing in quite a while now.
>>>>>>
>>>>>> however, both x87 and most of the deprecated instructions have been
>>>>>> kept around, kind of still needed if you want the processors to
>>>>>> still be able to run 16-bit or 32-bit software (or the possibility
>>>>>> of pesky runtime library implementers using x87 for
>>>>>> sin/cos/tan/... rather than calculating them via the Taylor Series
>>>>>> or similar).
>>>>>>
>>>>>
>>>>> What about extended precision float? Compilers still generate
>>>>> x87 instructions and take adequate parameters for that number?
>>>>>
>>>>
>>>> depends on compiler and OS.
>>>>
>>>> GCC and Linux, yes.
>>>>
>>>> had partly overlooked these.
>>>>
>>>> but, yes, it seems SysV/AMD64 still allows x87.
>>>>
>>>>
>>>> not sure what GCC does on Win64, but if they are using 80-bit floats
>>>> via x87 on Win64, this is basically a "thin ice" scenario AFAIK, and
>>>> may break hard in Ring-0 / WDM code or similar.
>>>>
>>> I think one can't use FPU / SSE at all in Linux drivers or perhaps
>>> can but with restrictions. But kernel itself compiles with
>>> switches that disable MMX/SSE completely I am positively sure.
>>> In user space - no problem. I guess this is the case with
>>> Windows , as well.
>>>
>>
>> AFAIK, in Win64, the x87 FPU and MMX are off limits (*), but SSE is OK
>> (its registers are preserved across context switches, unlike x87 or MMX).
>>
>>
>> *: MSDN describes their use in kernel mode as "strictly prohibited".
>> this was in contrast to 32-bit Windows where it was OK if you did some
>> special function calls to manage the FPU state, but apparently in 64-bit
>> mode these calls are no-op.
>>
>> if you use floating point in C code in drivers, this is OK, partly
>> because the compiler doesn't generate any x87 instructions.
>>
>>
>> in userland, they are preserved presumably so 32-bit applications still
>> work, but (like in the kernel), you still aren't really supposed to use
>> them in 64-bit code.
>
>
> No, the x87 and MMX instructions are fully supported in 64 bit user
> mode.  There was, a long time ago, some confusion caused by the kernel
> documentation being misinterpreted as applying to user mode.  The OS
> fully supports 64 bit applications using x87.
>

ok, I guess it makes about as much sense as "it just works for whatever 
reason...".

my information was mostly going off a mix of vague memory and 
web-searches (and some stumbling on MSDN). web-search results had 
generally claimed that they were also disallowed in 64-bit userland.


>
>>
>>>
>>>>
>>>> Microsoft's compiler treats "long double" as equivalent to "double",
>>>> so 80-bit floats don't really exist on Win64 to begin with, so no
>>>> issue here.
>>>
>>> I think that Microsoft wouldn't break anything like that, and that is
>>> why their long double treats as double. It made them easier to
>>> port to architectures that don't have extended precision float.
>>>
>>
>> in 32-bit code, they were treated as equivalent.
>>
>> after moving to 64-bit, there isn't a whole lot of reason for normal
>> code to ever touch x87 instructions.
>
>
> In general the SSE2 instructions are a much better target for most
> purposes.
>

yeah.

someone else mentioned they were using AVX, but FWIW, the CPU in my PC 
lacks AVX (granted, I am still using a CPU from last-decade as well, but 
it still works pretty good).

[toc] | [prev] | [next] | [standalone]

#59680

On Sun, 05 Apr 2015 23:09:14 -0500, BGB <cr88192@hotmail.com> wrote:

>On 4/5/2015 10:29 PM, Robert Wessel wrote:
>> On Sun, 05 Apr 2015 18:50:54 -0500, BGB <cr88192@hotmail.com> wrote:
>>
>>> On 4/5/2015 12:37 PM, Melzzzzz wrote:
>>>> On Sun, 05 Apr 2015 11:56:13 -0500
>>>> BGB <cr88192@hotmail.com> wrote:
>>>>
>>>>> On 4/5/2015 11:40 AM, Melzzzzz wrote:
>>>>>> On Sun, 05 Apr 2015 11:21:52 -0500
>>>>>> BGB <cr88192@hotmail.com> wrote:
>>>>>>
>>>>>>> On 4/5/2015 10:35 AM, Melzzzzz wrote:
>>>>>>>> On Sun, 05 Apr 2015 17:17:42 +0200
>>>>>>>> Noob <root@127.0.0.1> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> And x87 is obsolete.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Who said that?
>>>>>>>>
>>>>>>>
>>>>>>> AMD mostly.
>>>>>>>
>>>>>>>
>>>>>>> when they created the x86-64 / AMD64 ISA, IIRC they also classified
>>>>>>> x87 (among other things) as a deprecated feature. the main existing
>>>>>>> 64-bit ABIs (SysV/AMD64 and Win64) also regard x87 as deprecated
>>>>>>> AFAIK.
>>>>>>>
>>>>>>> I don't know if Intel has said anything on the matter, but either
>>>>>>> way, x87 hasn't really been a big thing in quite a while now.
>>>>>>>
>>>>>>> however, both x87 and most of the deprecated instructions have been
>>>>>>> kept around, kind of still needed if you want the processors to
>>>>>>> still be able to run 16-bit or 32-bit software (or the possibility
>>>>>>> of pesky runtime library implementers using x87 for
>>>>>>> sin/cos/tan/... rather than calculating them via the Taylor Series
>>>>>>> or similar).
>>>>>>>
>>>>>>
>>>>>> What about extended precision float? Compilers still generate
>>>>>> x87 instructions and take adequate parameters for that number?
>>>>>>
>>>>>
>>>>> depends on compiler and OS.
>>>>>
>>>>> GCC and Linux, yes.
>>>>>
>>>>> had partly overlooked these.
>>>>>
>>>>> but, yes, it seems SysV/AMD64 still allows x87.
>>>>>
>>>>>
>>>>> not sure what GCC does on Win64, but if they are using 80-bit floats
>>>>> via x87 on Win64, this is basically a "thin ice" scenario AFAIK, and
>>>>> may break hard in Ring-0 / WDM code or similar.
>>>>>
>>>> I think one can't use FPU / SSE at all in Linux drivers or perhaps
>>>> can but with restrictions. But kernel itself compiles with
>>>> switches that disable MMX/SSE completely I am positively sure.
>>>> In user space - no problem. I guess this is the case with
>>>> Windows , as well.
>>>>
>>>
>>> AFAIK, in Win64, the x87 FPU and MMX are off limits (*), but SSE is OK
>>> (its registers are preserved across context switches, unlike x87 or MMX).
>>>
>>>
>>> *: MSDN describes their use in kernel mode as "strictly prohibited".
>>> this was in contrast to 32-bit Windows where it was OK if you did some
>>> special function calls to manage the FPU state, but apparently in 64-bit
>>> mode these calls are no-op.
>>>
>>> if you use floating point in C code in drivers, this is OK, partly
>>> because the compiler doesn't generate any x87 instructions.
>>>
>>>
>>> in userland, they are preserved presumably so 32-bit applications still
>>> work, but (like in the kernel), you still aren't really supposed to use
>>> them in 64-bit code.
>>
>>
>> No, the x87 and MMX instructions are fully supported in 64 bit user
>> mode.  There was, a long time ago, some confusion caused by the kernel
>> documentation being misinterpreted as applying to user mode.  The OS
>> fully supports 64 bit applications using x87.
>>
>
>ok, I guess it makes about as much sense as "it just works for whatever 
>reason...".
>
>my information was mostly going off a mix of vague memory and 
>web-searches (and some stumbling on MSDN). web-search results had 
>generally claimed that they were also disallowed in 64-bit userland.


The ABI doc mentions that for user mode the x87 stack is saved across
context switches, but is otherwise not mentioned in the ABI, so unless
you know the called routine, you pretty much have to assume all of the
state is volatile across the call (IOW all of the FPU state is caller
save).

https://msdn.microsoft.com/en-us/library/ms235286.aspx


This is the clarified version of the documentation that caused all the
hubbub to begin with (they basically added the comments about user
mode contexts saving the x87 stack):

https://msdn.microsoft.com/en-us/library/windows/hardware/ff545910(v=vs.85).aspx

[toc] | [prev] | [next] | [standalone]

#59683

On 4/6/2015 1:54 AM, Robert Wessel wrote:
> On Sun, 05 Apr 2015 23:09:14 -0500, BGB <cr88192@hotmail.com> wrote:
>
>> On 4/5/2015 10:29 PM, Robert Wessel wrote:
>>> On Sun, 05 Apr 2015 18:50:54 -0500, BGB <cr88192@hotmail.com> wrote:
>>>
>>>> On 4/5/2015 12:37 PM, Melzzzzz wrote:
>>>>> On Sun, 05 Apr 2015 11:56:13 -0500
>>>>> BGB <cr88192@hotmail.com> wrote:
>>>>>
>>>>>> On 4/5/2015 11:40 AM, Melzzzzz wrote:
>>>>>>> On Sun, 05 Apr 2015 11:21:52 -0500
>>>>>>> BGB <cr88192@hotmail.com> wrote:
>>>>>>>
>>>>>>>> On 4/5/2015 10:35 AM, Melzzzzz wrote:
>>>>>>>>> On Sun, 05 Apr 2015 17:17:42 +0200
>>>>>>>>> Noob <root@127.0.0.1> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And x87 is obsolete.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Who said that?
>>>>>>>>>
>>>>>>>>
>>>>>>>> AMD mostly.
>>>>>>>>
>>>>>>>>
>>>>>>>> when they created the x86-64 / AMD64 ISA, IIRC they also classified
>>>>>>>> x87 (among other things) as a deprecated feature. the main existing
>>>>>>>> 64-bit ABIs (SysV/AMD64 and Win64) also regard x87 as deprecated
>>>>>>>> AFAIK.
>>>>>>>>
>>>>>>>> I don't know if Intel has said anything on the matter, but either
>>>>>>>> way, x87 hasn't really been a big thing in quite a while now.
>>>>>>>>
>>>>>>>> however, both x87 and most of the deprecated instructions have been
>>>>>>>> kept around, kind of still needed if you want the processors to
>>>>>>>> still be able to run 16-bit or 32-bit software (or the possibility
>>>>>>>> of pesky runtime library implementers using x87 for
>>>>>>>> sin/cos/tan/... rather than calculating them via the Taylor Series
>>>>>>>> or similar).
>>>>>>>>
>>>>>>>
>>>>>>> What about extended precision float? Compilers still generate
>>>>>>> x87 instructions and take adequate parameters for that number?
>>>>>>>
>>>>>>
>>>>>> depends on compiler and OS.
>>>>>>
>>>>>> GCC and Linux, yes.
>>>>>>
>>>>>> had partly overlooked these.
>>>>>>
>>>>>> but, yes, it seems SysV/AMD64 still allows x87.
>>>>>>
>>>>>>
>>>>>> not sure what GCC does on Win64, but if they are using 80-bit floats
>>>>>> via x87 on Win64, this is basically a "thin ice" scenario AFAIK, and
>>>>>> may break hard in Ring-0 / WDM code or similar.
>>>>>>
>>>>> I think one can't use FPU / SSE at all in Linux drivers or perhaps
>>>>> can but with restrictions. But kernel itself compiles with
>>>>> switches that disable MMX/SSE completely I am positively sure.
>>>>> In user space - no problem. I guess this is the case with
>>>>> Windows , as well.
>>>>>
>>>>
>>>> AFAIK, in Win64, the x87 FPU and MMX are off limits (*), but SSE is OK
>>>> (its registers are preserved across context switches, unlike x87 or MMX).
>>>>
>>>>
>>>> *: MSDN describes their use in kernel mode as "strictly prohibited".
>>>> this was in contrast to 32-bit Windows where it was OK if you did some
>>>> special function calls to manage the FPU state, but apparently in 64-bit
>>>> mode these calls are no-op.
>>>>
>>>> if you use floating point in C code in drivers, this is OK, partly
>>>> because the compiler doesn't generate any x87 instructions.
>>>>
>>>>
>>>> in userland, they are preserved presumably so 32-bit applications still
>>>> work, but (like in the kernel), you still aren't really supposed to use
>>>> them in 64-bit code.
>>>
>>>
>>> No, the x87 and MMX instructions are fully supported in 64 bit user
>>> mode.  There was, a long time ago, some confusion caused by the kernel
>>> documentation being misinterpreted as applying to user mode.  The OS
>>> fully supports 64 bit applications using x87.
>>>
>>
>> ok, I guess it makes about as much sense as "it just works for whatever
>> reason...".
>>
>> my information was mostly going off a mix of vague memory and
>> web-searches (and some stumbling on MSDN). web-search results had
>> generally claimed that they were also disallowed in 64-bit userland.
>
>
> The ABI doc mentions that for user mode the x87 stack is saved across
> context switches, but is otherwise not mentioned in the ABI, so unless
> you know the called routine, you pretty much have to assume all of the
> state is volatile across the call (IOW all of the FPU state is caller
> save).
>
> https://msdn.microsoft.com/en-us/library/ms235286.aspx
>
>
> This is the clarified version of the documentation that caused all the
> hubbub to begin with (they basically added the comments about user
> mode contexts saving the x87 stack):
>
> https://msdn.microsoft.com/en-us/library/windows/hardware/ff545910(v=vs.85).aspx
>

yes, ok.
makes sense.

[toc] | [prev] | [next] | [standalone]

#59731

On 05/04/15 19:37, Melzzzzz wrote:
> On Sun, 05 Apr 2015 11:56:13 -0500
> BGB <cr88192@hotmail.com> wrote:

>>
>> Microsoft's compiler treats "long double" as equivalent to "double",
>> so 80-bit floats don't really exist on Win64 to begin with, so no
>> issue here.
> 
> I think that Microsoft wouldn't break anything like that, and that is
> why their long double treats as double. It made them easier to
> port to architectures that don't have extended precision float.
> 

MS does not worry much about porting to different architectures.  But
they /are/ concerned about code compatibility despite notoriously lax
coding amongst windows programmers - thus in Win64 a "long" is 32-bit
rather than 64-bit like in most 64-bit OS's, to support code that is
written with the assumption that "long" is always 32-bit.  Making "long
double" and "double" the same on Windows keeps things easier for
programmers who don't pay due care to their types.

[toc] | [prev] | [next] | [standalone]

#59733

On Tue, 07 Apr 2015 10:16:37 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 05/04/15 19:37, Melzzzzz wrote:
>> On Sun, 05 Apr 2015 11:56:13 -0500
>> BGB <cr88192@hotmail.com> wrote:
>
>>>
>>> Microsoft's compiler treats "long double" as equivalent to "double",
>>> so 80-bit floats don't really exist on Win64 to begin with, so no
>>> issue here.
>> 
>> I think that Microsoft wouldn't break anything like that, and that is
>> why their long double treats as double. It made them easier to
>> port to architectures that don't have extended precision float.
>> 
>
>MS does not worry much about porting to different architectures.  But
>they /are/ concerned about code compatibility despite notoriously lax
>coding amongst windows programmers - thus in Win64 a "long" is 32-bit
>rather than 64-bit like in most 64-bit OS's, to support code that is
>written with the assumption that "long" is always 32-bit.  Making "long
>double" and "double" the same on Windows keeps things easier for
>programmers who don't pay due care to their types.


The dropping of 80-bit long doubles came about because MS *was*
worrying about cross platform issues.  80-bit floats were only
supported on x86, and MS was definitely intending non-x86 platforms
for NT.  MIPS, for example, shipped from day one (and was reportedly
where NT booted the first time).  Along the way they've supported
Alpha, PPC and (sort-of) ARM.  IPF, too, but that supported the 80-bit
type.

So the idea was that long doubles would be the same on all platforms.
I'm not going to defend that approach, but...  At least they could
have provided an x86-specific extended type, or even intrinsics, for
people still wanting to use the 80-bit type.   Which is more-or-less
similar to your argument.

Win16 versions of MS's language produces certainly supported 80-bit
long doubles.

[toc] | [prev] | [next] | [standalone]

#59745

On 07/04/15 10:32, Robert Wessel wrote:
> On Tue, 07 Apr 2015 10:16:37 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 05/04/15 19:37, Melzzzzz wrote:
>>> On Sun, 05 Apr 2015 11:56:13 -0500
>>> BGB <cr88192@hotmail.com> wrote:
>>
>>>>
>>>> Microsoft's compiler treats "long double" as equivalent to "double",
>>>> so 80-bit floats don't really exist on Win64 to begin with, so no
>>>> issue here.
>>>
>>> I think that Microsoft wouldn't break anything like that, and that is
>>> why their long double treats as double. It made them easier to
>>> port to architectures that don't have extended precision float.
>>>
>>
>> MS does not worry much about porting to different architectures.  But
>> they /are/ concerned about code compatibility despite notoriously lax
>> coding amongst windows programmers - thus in Win64 a "long" is 32-bit
>> rather than 64-bit like in most 64-bit OS's, to support code that is
>> written with the assumption that "long" is always 32-bit.  Making "long
>> double" and "double" the same on Windows keeps things easier for
>> programmers who don't pay due care to their types.
> 
> 
> The dropping of 80-bit long doubles came about because MS *was*
> worrying about cross platform issues.  80-bit floats were only
> supported on x86, and MS was definitely intending non-x86 platforms
> for NT.  MIPS, for example, shipped from day one (and was reportedly
> where NT booted the first time).  Along the way they've supported
> Alpha, PPC and (sort-of) ARM.  IPF, too, but that supported the 80-bit
> type.

I did not realise the decision about dropping 80-bit long doubles was
that old.  Yes, MS used to be more interested in portability with
support for different targets, but that's a long time ago (except for
sort-of support for Itanium and sort-of support for ARM and other
Wince/Winphone cpus).

> 
> So the idea was that long doubles would be the same on all platforms.
> I'm not going to defend that approach, but...  At least they could
> have provided an x86-specific extended type, or even intrinsics, for
> people still wanting to use the 80-bit type.   Which is more-or-less
> similar to your argument.
> 
> Win16 versions of MS's language produces certainly supported 80-bit
> long doubles.
> 

[toc] | [prev] | [next] | [standalone]

#59746

On 07/04/15 11:48, David Brown wrote:

<snip>

> I did not realise the decision about dropping 80-bit long doubles was
> that old.

Some time in 1994.

Visual C++ 1.52 (AFAIK, the last 1.x version) supported 80-bit doubles.

Visual C++ 2.x did not.

The first release of Visual C++ 1.5x seems to have been in December 
1993, and Visual C++ 2.x certainly pre-dated Windows 95. When I bought 
the latter, the former was included on the same CD-ROM.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59751

On 07/04/15 12:57, Richard Heathfield wrote:
> On 07/04/15 11:48, David Brown wrote:
> 
> <snip>
> 
>> I did not realise the decision about dropping 80-bit long doubles was
>> that old.
> 
> Some time in 1994.
> 
> Visual C++ 1.52 (AFAIK, the last 1.x version) supported 80-bit doubles.
> 
> Visual C++ 2.x did not.
> 
> The first release of Visual C++ 1.5x seems to have been in December
> 1993, and Visual C++ 2.x certainly pre-dated Windows 95. When I bought
> the latter, the former was included on the same CD-ROM.
> 
> <snip>
> 

At that time I was using Borland Pascal - which, IIRC, supported
floating point types of size 4, 6, 8 and 10 bytes - with the 6 byte
version being the favourite.

But then, Borland was its own standard.

[toc] | [prev] | [next] | [standalone]

#59779

On Tue, 07 Apr 2015 11:57:57 +0100, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>On 07/04/15 11:48, David Brown wrote:
>
><snip>
>
>> I did not realise the decision about dropping 80-bit long doubles was
>> that old.
>
>Some time in 1994.
>
>Visual C++ 1.52 (AFAIK, the last 1.x version) supported 80-bit doubles.
>
>Visual C++ 2.x did not.
>
>The first release of Visual C++ 1.5x seems to have been in December 
>1993, and Visual C++ 2.x certainly pre-dated Windows 95. When I bought 
>the latter, the former was included on the same CD-ROM.


It was the 32-bit compilers that had long double as 64-bit floats, it
was not release dependent.  I don't remember when the first 32-bit
version of MSVC happened*, but there was a 32-bit version of v1.5x,
and it had 64-bit long doubles.  The 16-bit version of v1.5x (shipped
in the same package, IIRC) had 80-bit long doubles.  MSVC v2.0 did not
have a 16-bit version (except, as you noted, by including a version of
v1.5x).

Win32 rather predates Win95.  


*IIRC, there was at least one 32-bit compiler prior to the v1.5x one,
but it may have been of somewhat limited release.

[toc] | [prev] | [next] | [standalone]

#59772

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip)

> The dropping of 80-bit long doubles came about because MS *was*
> worrying about cross platform issues.  80-bit floats were only
> supported on x86, and MS was definitely intending non-x86 platforms
> for NT.  MIPS, for example, shipped from day one (and was reportedly
> where NT booted the first time).  Along the way they've supported
> Alpha, PPC and (sort-of) ARM.  IPF, too, but that supported the 80-bit
> type.


OK, but the reason for the 80 bit temporary real format is for
intermediate values in calculations. That allows one to do
simple calculations without losing bits. 

-- glen

[toc] | [prev] | [next] | [standalone]

#59773

On 4/7/2015 1:15 PM, glen herrmannsfeldt wrote:
> Robert Wessel <robertwessel2@yahoo.com> wrote:
> 
> (snip)
> 
>> The dropping of 80-bit long doubles came about because MS *was*
>> worrying about cross platform issues.  80-bit floats were only
>> supported on x86, and MS was definitely intending non-x86 platforms
>> for NT.  MIPS, for example, shipped from day one (and was reportedly
>> where NT booted the first time).  Along the way they've supported
>> Alpha, PPC and (sort-of) ARM.  IPF, too, but that supported the 80-bit
>> type.
> 
> 
> OK, but the reason for the 80 bit temporary real format is for
> intermediate values in calculations. That allows one to do
> simple calculations without losing bits. 
> 
> -- glen
> 
Years ago, Microsoft began expecting that applications would set 53-bit
precision mode so as to disable the extra precision (but not the
exponent range protection), and also set their compilers to use 64-bit
data for long double.
Their first beta software for x64 didn't allow x87 instructions, and
this was after those other platforms were on the way out.  Then they
allowed x87 but 53-bit mode is set before a .exe starts.
Some library functions appear to be broken if called with 64-bit mode
enabled, which is not intended to be supported.

The early SSE2 platforms had different ways in which x87 code was no
longer competitive, more frequently so on Pentium 4 than Athlon.  So
there seemed to be a clear policy against full x87 support from then on.

[toc] | [prev] | [next] | [standalone]

#59649

BGB <cr88192@hotmail.com> writes:
[...]
> Microsoft's compiler treats "long double" as equivalent to "double",
> so 80-bit floats don't really exist on Win64 to begin with, so no
> issue here.

That depends on what you mean by "equivalent".  `double` and
`long double` are still distinct types, even if they have the same
representation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59658

On 4/5/2015 3:08 PM, Keith Thompson wrote:
> BGB <cr88192@hotmail.com> writes:
> [...]
>> Microsoft's compiler treats "long double" as equivalent to "double",
>> so 80-bit floats don't really exist on Win64 to begin with, so no
>> issue here.
>
> That depends on what you mean by "equivalent".  `double` and
> `long double` are still distinct types, even if they have the same
> representation.
>

they have the same size and representation and precision, and are 
treated the same at the ABI level.

[toc] | [prev] | [next] | [standalone]

#59636

On 05/04/2015 18:40, Melzzzzz wrote:

> What about extended precision float? Compilers still generate
> x87 instructions and take adequate parameters for that number?

Compilers are allowed to alias 'long double' to 'double'.
Microsoft's compiler does it. So does Intel's by default.

https://en.wikipedia.org/wiki/Long_double#Implementations

(Let's try to keep this sub-thread on topic.)

Regards.

[toc] | [prev] | [next] | [standalone]

#59642

On Sun, 05 Apr 2015 19:04:14 +0200
Noob <root@127.0.0.1> wrote:

> On 05/04/2015 18:40, Melzzzzz wrote:
> 
> > What about extended precision float? Compilers still generate
> > x87 instructions and take adequate parameters for that number?
> 
> Compilers are allowed to alias 'long double' to 'double'.

Yes, but I don't consider that as an advantage.

> Microsoft's compiler does it. So does Intel's by default.
> 
> https://en.wikipedia.org/wiki/Long_double#Implementations
> 
> (Let's try to keep this sub-thread on topic.)

Ok.

> 
> Regards.
> 

Same to you ;)

[toc] | [prev] | [next] | [standalone]

#59644

W dniu niedziela, 5 kwietnia 2015 19:38:34 UTC+2 użytkownik Melzzzzz napisał:
> > (Let's try to keep this sub-thread on topic.)
> 
> Ok.
> 
> > 
> > Regards.
> > 
> 
> Same to you ;)

imo you should care more about not discussing 
ufo here to much but not hardware grounds

as i said if tgis is only group about "c language" and not "programmming in c" where is this second group for programming in c ?
(there is no one afaik so imo this means this group is both ofr c language and for wider 
topics of programming in c)
(that is my personal opinion)

[toc] | [prev] | [next] | [standalone]

#59650

Noob <root@127.0.0.1> writes:
> On 05/04/2015 18:40, Melzzzzz wrote:
>> What about extended precision float? Compilers still generate
>> x87 instructions and take adequate parameters for that number?
>
> Compilers are allowed to alias 'long double' to 'double'.
> Microsoft's compiler does it. So does Intel's by default.

No, they are not.  `double` and `long double` are still distinct types,
even if they have the same representation.  For example, this:

    double x;
    long double *ptr = &x;

is a constraint violation regardless of the representations of the
types.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59633

W dniu niedziela, 5 kwietnia 2015 18:25:34 UTC+2 użytkownik BGB napisał:
> On 4/5/2015 10:35 AM, Melzzzzz wrote:
> > On Sun, 05 Apr 2015 17:17:42 +0200
> > Noob <root@127.0.0.1> wrote:
> >
> >>
> >> And x87 is obsolete.
> >>
> >
> > Who said that?
> >
> 
> AMD mostly.
> 
> 
> when they created the x86-64 / AMD64 ISA, IIRC they also classified x87 
> (among other things) as a deprecated feature. the main existing 64-bit 
> ABIs (SysV/AMD64 and Win64) also regard x87 as deprecated AFAIK.
> 
> I don't know if Intel has said anything on the matter, but either way, 
> x87 hasn't really been a big thing in quite a while now.
> 
> however, both x87 and most of the deprecated instructions have been kept 
> around, kind of still needed if you want the processors to still be able 
> to run 16-bit or 32-bit software (or the possibility of pesky runtime 
> library implementers using x87 for sin/cos/tan/... rather than 
> calculating them via the Taylor Series or similar).

as far as i know, if you made gcc to use BOTH
x87 and sse  you got the best efficiency

from gcc docs about "-mfpmath=both " ->
 
Attempt to utilize both instruction sets at once. This effectively double the amount of available registers and on chips with separate execution units for 387 and SSE the execution resources too. Use this option with care, as it is still experimental, because the GCC register allocator does not model separate functional units well resulting in instable performance.

I test it from time to time and as far as i test it seem fastests option

[toc] | [prev] | [next] | [standalone]

#59640

On 4/5/2015 11:51 AM, fir wrote:
> W dniu niedziela, 5 kwietnia 2015 18:25:34 UTC+2 użytkownik BGB napisał:
>> On 4/5/2015 10:35 AM, Melzzzzz wrote:
>>> On Sun, 05 Apr 2015 17:17:42 +0200
>>> Noob <root@127.0.0.1> wrote:
>>>
>>>>
>>>> And x87 is obsolete.
>>>>
>>>
>>> Who said that?
>>>
>>
>> AMD mostly.
>>
>>
>> when they created the x86-64 / AMD64 ISA, IIRC they also classified x87
>> (among other things) as a deprecated feature. the main existing 64-bit
>> ABIs (SysV/AMD64 and Win64) also regard x87 as deprecated AFAIK.
>>
>> I don't know if Intel has said anything on the matter, but either way,
>> x87 hasn't really been a big thing in quite a while now.
>>
>> however, both x87 and most of the deprecated instructions have been kept
>> around, kind of still needed if you want the processors to still be able
>> to run 16-bit or 32-bit software (or the possibility of pesky runtime
>> library implementers using x87 for sin/cos/tan/... rather than
>> calculating them via the Taylor Series or similar).
>
> as far as i know, if you made gcc to use BOTH
> x87 and sse  you got the best efficiency
>
> from gcc docs about "-mfpmath=both " ->
>
> Attempt to utilize both instruction sets at once. This effectively double the amount of available registers and on chips with separate execution units for 387 and SSE the execution resources too. Use this option with care, as it is still experimental, because the GCC register allocator does not model separate functional units well resulting in instable performance.
>
> I test it from time to time and as far as i test it seem fastests option
>

"it depends"...

if you use both and have a processor with a shared FPU, then 
floating-point intensive multi-threaded code performance may suffer 
(even if the single-threaded case is faster).

as noted already, AMD and Intel have different opinions on these 
matters, apparently as well as Linux-land and Microsoft.

in most normal cases, it still works though.

[toc] | [prev] | [next] | [standalone]

#59667

Le 05/04/2015 17:35, Melzzzzz a écrit :
> On Sun, 05 Apr 2015 17:17:42 +0200
> Noob <root@127.0.0.1> wrote:
>
>>
>> And x87 is obsolete.
>>
>
> Who said that?
>
lcc-win was generating a fsin instruction to calculate the sin(x) using 
the x87

I was completely ASTONISHED that gcc was much faster. They had an 
optimized sin routine in SSE and their routine was faster than a SINGLE 
FPU instruction...

Intel hasn't upgraded the x87 since at least 10-15 years...

I still generate fsin though...

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web