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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#59695

On Mon, 06 Apr 2015 08:57:43 -0500, BGB <cr88192@hotmail.com> wrote:

>On 4/6/2015 2:06 AM, Robert Wessel wrote:
>> On Sun, 5 Apr 2015 23:39:16 -0700 (PDT), Weng Tianxiang
>> <wtxwtx@gmail.com> wrote:
>>
>>> On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>>>> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>>>> <wtxwtx@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>> Does each core of 8-core Intel processor has an independent floating X87 unit?
>>>>>
>>>>> Here are some texts from Intel latest datasheet:
>>>>>
>>>>> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket
>>>>> Datasheet - Volume 1 of 2
>>>>>
>>>>> Processor Feature Details
>>>>> *Up to 8 execution cores
>>>>> *Each core supports two threads (Intel(R) Hyper-Threading Technology)
>>>>> *32 KB instruction and 32 KB data first-level cache (L1) for each core
>>>>> *256 KB shared instruction/data mid-level (L2) cache for each core
>>>>> *Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores.
>>>>>
>>>>> 5.2 X87 FPU INSTRUCTIONS
>>>>> The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>>>>>
>>>>> These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions.
>>>>>
>>>> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit.
>>>>>
>>>>> Am I right or not?
>>>>>
>>>>> Is there anyone who has real experiences with X87 FPU unit?
>>>>
>>>>
>>>>
>>>> All current Intel x86s have the FPU on each core.  Some recent AMD
>>>> processors have had an FPU shared between two cores.
>>>
>>> Robert,
>>> Thank you for your reply.
>>>
>>> The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
>>>
>>>> The x87 FPU instructions are executed by the processor's x87 FPU.
>>>
>>> Where do you know "All current Intel x86s have the FPU on each core"?
>>
>>
>> The architectural documents specify nothing at all about the location
>> of the FPUs.  They describe its function, not its implementation.  For
>> all the architectural documents care, the CPU could be emailing a
>> server in Wyoming to get FPU operations performed.  They're considered
>> somewhat separately for historical reasons - pre-486, the FPU was
>> actually a separate chip, and often not included in a system (even on
>> 486s they were often not included, but the FPU was on the processor
>> chip).
>>
>
>IIRC, with the 486SX, the FPU was still in the processor (early on), 
>just they had it disabled. with the 486DX line, it was always enabled. 
>later on, the 486SX line went and apparently omitted the FPU entirely.


If you had an FPU on a 486 system, it was on-chip.  If you had a 486SX
system with a 487 socket, the "487" was an entire 486 CPU (with FPU
enabled) that sat in the socket next to the (now) disabled 486SX.

While it's true that the early 486SXs actually had the transistors for
the FPU on-die, but disabled, that's an implementation detail - it
still wasn't there from the user's perspective (and you still needed
the additional 487SX chip to get an FPU).


>with the 386 and earlier, I think most people didn't have FPUs.


That's certainly true.  And there were a couple of alternative math
coprocessers in that era too (the one from Weitek being the most
famous).


>IIRC, the first computer I had after having an 8088, was a 386SX (it had 
>the CPU soldered directly to the MOBO as a QFP-style package, and SIMMs 
>in place of discrete RAM chips).
>
>this was also back in the days where newer computers had ATA/IDE, but a 
>lot of the computers around still used ST-506 drives (and most of the 
>processors and other chips in PCs were still DIP based).
>
>so, in a way, the 386 was a bridge between the older and newer styles of 
>electronics, like the rise of surface-mount chips, displacing the pretty 
>much entirely DIP boards that were the 8088 and 286.


The package is rather irrelevant, but I don't believe any 186, 286, or
386 ever came in a DIP.  8086/8s certainly did (although I believe
there were some fairly rare non-DIP packages).


>> If you want to know how it's implemented, you need to look at some of
>> the implementation details reveal by Intel, often at venues like Hot
>> Chips, or look at one of the micro-architectural overview like this
>> one:
>>
>> http://www.realworldtech.com/haswell-cpu/
>>
>> There is, of course, nothing to prevent Intel from building a CPU
>> tomorrow with an FPU shared between cores (after all AMD already does
>> that), but latency issues and the modest size of the scalar FPU makes
>> it only a modest win.  In AMD's case, they shared the entire FPU (x87,
>> MMX, SSE, etc.) between cores.  A complication in any sort of shared
>> scheme is that all the cores sharing the FPU need their own set of
>> registers and such.
>>
>
>I am using an AMD CPU, FWIW.


The OP asked specifically about Intel's devices.  Obviously AMD (as
well as the other x86 vendors), did their own thing.


>> For just the x87, a bunch of what's needed for the x87 is needed
>> anyway for SSE support, so separating just the x87 support is really
>> unlikely to be worthwhile.  If Intel decided to depreciate x87
>> support, I suspect it would be by reducing most of the x87
>> instructions to microcode, which did most of the work under the hood
>> on the SSE hardware - wherever that hardware might be - but it still
>> wouldn't likely be moved out by itself).
>>
>
>yeah, maybe they could fake the x87 by doing all floating-point math 
>using doubles (and/or add 128 bit float support), and do all the MMX 
>stuff using SSE operations.
>
>I guess you would need some special hidden registers and similar for 
>this though.


On the high end CPUs there are already far more physical registers
than architectural ones, they could just use those.  They'd still need
the proper microcode.  Obviously the biggest nuisance would be dealing
with the 80-bit format if there were no hardware support at all.

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

#59711

On 4/6/2015 12:38 PM, Robert Wessel wrote:
> On Mon, 06 Apr 2015 08:57:43 -0500, BGB <cr88192@hotmail.com> wrote:
>
>> On 4/6/2015 2:06 AM, Robert Wessel wrote:
>>> On Sun, 5 Apr 2015 23:39:16 -0700 (PDT), Weng Tianxiang
>>> <wtxwtx@gmail.com> wrote:
>>>
>>>> On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>>>>> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>>>>> <wtxwtx@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Does each core of 8-core Intel processor has an independent floating X87 unit?
>>>>>>
>>>>>> Here are some texts from Intel latest datasheet:
>>>>>>
>>>>>> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket
>>>>>> Datasheet - Volume 1 of 2
>>>>>>
>>>>>> Processor Feature Details
>>>>>> *Up to 8 execution cores
>>>>>> *Each core supports two threads (Intel(R) Hyper-Threading Technology)
>>>>>> *32 KB instruction and 32 KB data first-level cache (L1) for each core
>>>>>> *256 KB shared instruction/data mid-level (L2) cache for each core
>>>>>> *Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores.
>>>>>>
>>>>>> 5.2 X87 FPU INSTRUCTIONS
>>>>>> The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>>>>>>
>>>>>> These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions.
>>>>>>
>>>>> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit.
>>>>>>
>>>>>> Am I right or not?
>>>>>>
>>>>>> Is there anyone who has real experiences with X87 FPU unit?
>>>>>
>>>>>
>>>>>
>>>>> All current Intel x86s have the FPU on each core.  Some recent AMD
>>>>> processors have had an FPU shared between two cores.
>>>>
>>>> Robert,
>>>> Thank you for your reply.
>>>>
>>>> The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
>>>>
>>>>> The x87 FPU instructions are executed by the processor's x87 FPU.
>>>>
>>>> Where do you know "All current Intel x86s have the FPU on each core"?
>>>
>>>
>>> The architectural documents specify nothing at all about the location
>>> of the FPUs.  They describe its function, not its implementation.  For
>>> all the architectural documents care, the CPU could be emailing a
>>> server in Wyoming to get FPU operations performed.  They're considered
>>> somewhat separately for historical reasons - pre-486, the FPU was
>>> actually a separate chip, and often not included in a system (even on
>>> 486s they were often not included, but the FPU was on the processor
>>> chip).
>>>
>>
>> IIRC, with the 486SX, the FPU was still in the processor (early on),
>> just they had it disabled. with the 486DX line, it was always enabled.
>> later on, the 486SX line went and apparently omitted the FPU entirely.
>
>
> If you had an FPU on a 486 system, it was on-chip.  If you had a 486SX
> system with a 487 socket, the "487" was an entire 486 CPU (with FPU
> enabled) that sat in the socket next to the (now) disabled 486SX.
>
> While it's true that the early 486SXs actually had the transistors for
> the FPU on-die, but disabled, that's an implementation detail - it
> still wasn't there from the user's perspective (and you still needed
> the additional 487SX chip to get an FPU).
>

yeah.


>
>> with the 386 and earlier, I think most people didn't have FPUs.
>
>
> That's certainly true.  And there were a couple of alternative math
> coprocessers in that era too (the one from Weitek being the most
> famous).
>

yeah. dunno what ISA the Weitek used (x87 or something different).
by the time I was starting to get much into programming, I was using a 
486DX.


>
>> IIRC, the first computer I had after having an 8088, was a 386SX (it had
>> the CPU soldered directly to the MOBO as a QFP-style package, and SIMMs
>> in place of discrete RAM chips).
>>
>> this was also back in the days where newer computers had ATA/IDE, but a
>> lot of the computers around still used ST-506 drives (and most of the
>> processors and other chips in PCs were still DIP based).
>>
>> so, in a way, the 386 was a bridge between the older and newer styles of
>> electronics, like the rise of surface-mount chips, displacing the pretty
>> much entirely DIP boards that were the 8088 and 286.
>
>
> The package is rather irrelevant, but I don't believe any 186, 286, or
> 386 ever came in a DIP.  8086/8s certainly did (although I believe
> there were some fairly rare non-DIP packages).
>

my memory is pretty weak here (very long ago and I was pretty young 
still), but I had remembered 286 boards as still mostly having DIP chips 
on them. looking into it, I now remember seeing the PLCC and LCC 
processors, but had almost forgotten about them.

but, I was thinking partly in terms of aesthetic, namely what the inside 
of an 8088 looked like, was very different than, say, a typical 386 or 486.

comparably, things had not changed quite as drastically in the following 
years. likewise, the move from 32 to 64 bit did not also come with a 
matching aesthetic shift.


though, FWIW, the 286 is older than I am, but widespread use of 
obsolescent hardware was pretty common in the 90s.


>
>>> If you want to know how it's implemented, you need to look at some of
>>> the implementation details reveal by Intel, often at venues like Hot
>>> Chips, or look at one of the micro-architectural overview like this
>>> one:
>>>
>>> http://www.realworldtech.com/haswell-cpu/
>>>
>>> There is, of course, nothing to prevent Intel from building a CPU
>>> tomorrow with an FPU shared between cores (after all AMD already does
>>> that), but latency issues and the modest size of the scalar FPU makes
>>> it only a modest win.  In AMD's case, they shared the entire FPU (x87,
>>> MMX, SSE, etc.) between cores.  A complication in any sort of shared
>>> scheme is that all the cores sharing the FPU need their own set of
>>> registers and such.
>>>
>>
>> I am using an AMD CPU, FWIW.
>
>
> The OP asked specifically about Intel's devices.  Obviously AMD (as
> well as the other x86 vendors), did their own thing.
>

yeah.

I was responding to the mention of AMD by noting that I am using an AMD 
processor. I am much less well versed on the specifics of the various 
micro-architectures though.


>
>>> For just the x87, a bunch of what's needed for the x87 is needed
>>> anyway for SSE support, so separating just the x87 support is really
>>> unlikely to be worthwhile.  If Intel decided to depreciate x87
>>> support, I suspect it would be by reducing most of the x87
>>> instructions to microcode, which did most of the work under the hood
>>> on the SSE hardware - wherever that hardware might be - but it still
>>> wouldn't likely be moved out by itself).
>>>
>>
>> yeah, maybe they could fake the x87 by doing all floating-point math
>> using doubles (and/or add 128 bit float support), and do all the MMX
>> stuff using SSE operations.
>>
>> I guess you would need some special hidden registers and similar for
>> this though.
>
>
> On the high end CPUs there are already far more physical registers
> than architectural ones, they could just use those.  They'd still need
> the proper microcode.  Obviously the biggest nuisance would be dealing
> with the 80-bit format if there were no hardware support at all.
>

possibly, but this could be mostly a hack with the load/store 
instructions (to pretend that the 80 bit format still exists).

granted, if they were handled internally using doubles, there would be a 
loss of precision and possibly differing results on calculations vs 
using 80 bits internally.

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

#59712

On 06-Apr-15 16:30, BGB wrote:
> but, I was thinking partly in terms of aesthetic, namely what the
> inside of an 8088 looked like, was very different than, say, a
> typical 386 or 486.
> 
> comparably, things had not changed quite as drastically in the
> following years. likewise, the move from 32 to 64 bit did not also
> come with a matching aesthetic shift.

There were significant changes in every generation for a while:

286 - protected mode
386 - 32-bit registers/addresses
486 - on-die FPU, L1 cache
P5 - superscalar, branch prediction
P55 - SIMD
P6 - OoO RISC core, L2 cache
P4 - NetBurst

Then things stalled for a few years. Intel had invested heavily in
NetBurst and Itanic, and both were utter failures.  Fortunately for
them, they were able to rework the P6 arch into the low-power PM arch
and make a comeback, but it gave AMD an opening to introduce a major
arch change of their own: 64-bit mode.

Intel's inertia means they can survive such mistakes, and AMD's on the
back foot again, though I'm sure they're ready and waiting to exploit
Intel's next mistake.  It's a repeating cycle, and that competitive
pressure is the main reason x86 is so successful despite its flaws.
IOW, with enough thrust (money), pigs _can_ fly.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#59714 — Re: Does each core of 8-core Intel processor has an independent floating X87 unit?

Stephen Sprunk wrote:
> On 06-Apr-15 16:30, BGB wrote:
>> but, I was thinking partly in terms of aesthetic, namely what the
>> inside of an 8088 looked like, was very different than, say, a
>> typical 386 or 486.
>>
>> comparably, things had not changed quite as drastically in the
>> following years. likewise, the move from 32 to 64 bit did not also
>> come with a matching aesthetic shift.
>
> There were significant changes in every generation for a while:
>
> 286 - protected mode
> 386 - 32-bit registers/addresses
> 486 - on-die FPU, L1 cache
> P5 - superscalar, branch prediction
> P55 - SIMD
> P6 - OoO RISC core, L2 cache
> P4 - NetBurst
>
> Then things stalled for a few years. Intel had invested heavily in
> NetBurst and Itanic, and both were utter failures.  Fortunately for
> them, they were able to rework the P6 arch into the low-power PM arch
> and make a comeback, but it gave AMD an opening to introduce a major
> arch change of their own: 64-bit mode.
>
> Intel's inertia means they can survive such mistakes, and AMD's on the
> back foot again, though I'm sure they're ready and waiting to exploit
> Intel's next mistake.  It's a repeating cycle, and that competitive
> pressure is the main reason x86 is so successful despite its flaws.
> IOW, with enough thrust (money), pigs _can_ fly.

No amount of money could make Itanic fly!

-- 
Ian Collins

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

#59722 — Re: Does each core of 8-core Intel processor has an independent floating X87 unit?

On Tue, 07 Apr 2015 10:16:42 +1200
Ian Collins <ian-news@hotmail.com> wrote:

> Stephen Sprunk wrote:
> > On 06-Apr-15 16:30, BGB wrote:
> >> but, I was thinking partly in terms of aesthetic, namely what the
> >> inside of an 8088 looked like, was very different than, say, a
> >> typical 386 or 486.
> >>
> >> comparably, things had not changed quite as drastically in the
> >> following years. likewise, the move from 32 to 64 bit did not also
> >> come with a matching aesthetic shift.
> >
> > There were significant changes in every generation for a while:
> >
> > 286 - protected mode
> > 386 - 32-bit registers/addresses
> > 486 - on-die FPU, L1 cache
> > P5 - superscalar, branch prediction
> > P55 - SIMD
> > P6 - OoO RISC core, L2 cache
> > P4 - NetBurst
> >
> > Then things stalled for a few years. Intel had invested heavily in
> > NetBurst and Itanic, and both were utter failures.  Fortunately for
> > them, they were able to rework the P6 arch into the low-power PM
> > arch and make a comeback, but it gave AMD an opening to introduce a
> > major arch change of their own: 64-bit mode.
> >
> > Intel's inertia means they can survive such mistakes, and AMD's on
> > the back foot again, though I'm sure they're ready and waiting to
> > exploit Intel's next mistake.  It's a repeating cycle, and that
> > competitive pressure is the main reason x86 is so successful
> > despite its flaws. IOW, with enough thrust (money), pigs _can_ fly.
> 
> No amount of money could make Itanic fly!
> 

Intel planned seriously to replace x86 with Itanic, but AMD nailed it
with amd64 architecture. 

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

#59719

On 4/6/2015 5:10 PM, Stephen Sprunk wrote:
> On 06-Apr-15 16:30, BGB wrote:
>> but, I was thinking partly in terms of aesthetic, namely what the
>> inside of an 8088 looked like, was very different than, say, a
>> typical 386 or 486.
>>
>> comparably, things had not changed quite as drastically in the
>> following years. likewise, the move from 32 to 64 bit did not also
>> come with a matching aesthetic shift.
>
> There were significant changes in every generation for a while:
>
> 286 - protected mode
> 386 - 32-bit registers/addresses
> 486 - on-die FPU, L1 cache
> P5 - superscalar, branch prediction
> P55 - SIMD
> P6 - OoO RISC core, L2 cache
> P4 - NetBurst
>
> Then things stalled for a few years. Intel had invested heavily in
> NetBurst and Itanic, and both were utter failures.  Fortunately for
> them, they were able to rework the P6 arch into the low-power PM arch
> and make a comeback, but it gave AMD an opening to introduce a major
> arch change of their own: 64-bit mode.
>

yes.


> Intel's inertia means they can survive such mistakes, and AMD's on the
> back foot again, though I'm sure they're ready and waiting to exploit
> Intel's next mistake.  It's a repeating cycle, and that competitive
> pressure is the main reason x86 is so successful despite its flaws.
> IOW, with enough thrust (money), pigs _can_ fly.
>

I suspect something which may start to be an issue in a few years is the 
centralization of x86 with Intel and AMD, compared with ARM devices 
which can be fabricated by 3rd parties (with royalties paid back to ARM).


I suspect there may be a need to have embedded core designs more open to 
fabrication by 3rd parties, or risk over time steadily losing ground to 
ARM based devices.

I suspect though that Intel would try to avoid going this route, which 
could risk eventually putting their dominance on PCs at risk (if the 
trend continues of OS's and applications becoming increasingly 
multi-architecture).

open cores could however help further increase the spread of x86 into 
embedded spaces, and would help maintain Intel and AMD's dominance 
provided they can keep producing the highest performance parts (but 
could also lead to a risk of creating increased competition if their 
performance advantage is not maintained).

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

#59720

On Mon, 06 Apr 2015 16:30:14 -0500, BGB <cr88192@hotmail.com> wrote:

>On 4/6/2015 12:38 PM, Robert Wessel wrote:
>> On Mon, 06 Apr 2015 08:57:43 -0500, BGB <cr88192@hotmail.com> wrote:
>>
>>> On 4/6/2015 2:06 AM, Robert Wessel wrote:

>> That's certainly true.  And there were a couple of alternative math
>> coprocessers in that era too (the one from Weitek being the most
>> famous).
>>
>
>yeah. dunno what ISA the Weitek used (x87 or something different).
>by the time I was starting to get much into programming, I was using a 
>486DX.


The Weitek, at least the generation I was familiar with, didn't
implement anything like the x87 ISA, rather it sported a memory mapped
interface that triggered operations based on what address you wrote
to.


>though, FWIW, the 286 is older than I am, but widespread use of 
>obsolescent hardware was pretty common in the 90s.


Gee thanks.  I feel old now.  ;-)


>possibly, but this could be mostly a hack with the load/store 
>instructions (to pretend that the 80 bit format still exists).
>
>granted, if they were handled internally using doubles, there would be a 
>loss of precision and possibly differing results on calculations vs 
>using 80 bits internally.


I don't think that would do at all.  But even if you had nothing but
the normal 64 bit floats, the algorithms for double precision FP
haven't been any sort of secret since at least the sixties.

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

#59723

On 4/6/2015 5:41 PM, Robert Wessel wrote:
> On Mon, 06 Apr 2015 16:30:14 -0500, BGB <cr88192@hotmail.com> wrote:
>
>> On 4/6/2015 12:38 PM, Robert Wessel wrote:
>>> On Mon, 06 Apr 2015 08:57:43 -0500, BGB <cr88192@hotmail.com> wrote:
>>>
>>>> On 4/6/2015 2:06 AM, Robert Wessel wrote:
>
>>> That's certainly true.  And there were a couple of alternative math
>>> coprocessers in that era too (the one from Weitek being the most
>>> famous).
>>>
>>
>> yeah. dunno what ISA the Weitek used (x87 or something different).
>> by the time I was starting to get much into programming, I was using a
>> 486DX.
>
>
> The Weitek, at least the generation I was familiar with, didn't
> implement anything like the x87 ISA, rather it sported a memory mapped
> interface that triggered operations based on what address you wrote
> to.
>

errm... yeah...

then again, I guess I deal with vaguely similar dealing with things like 
GPIO on ARM devices, where you basically write bit-masks to various 
locations to set and clear the various output pins (*), and write 
bit-masks to set the mode of various pins (usually, between input, 
output, or sometimes a pin-specific special mode).

*: writing a value to one location, any set bits will set the 
corresponding pin, and to another location, any set bits will clear the pin.

now, as to why it couldn't behave more like normal memory, who knows?...


>
>> though, FWIW, the 286 is older than I am, but widespread use of
>> obsolescent hardware was pretty common in the 90s.
>
>
> Gee thanks.  I feel old now.  ;-)
>

I am left to feel old compared with other people in a class I am taking.
most of them were born in the mid/late 90s, and I am also several years 
older than the teacher as well.


>
>> possibly, but this could be mostly a hack with the load/store
>> instructions (to pretend that the 80 bit format still exists).
>>
>> granted, if they were handled internally using doubles, there would be a
>> loss of precision and possibly differing results on calculations vs
>> using 80 bits internally.
>
>
> I don't think that would do at all.  But even if you had nothing but
> the normal 64 bit floats, the algorithms for double precision FP
> haven't been any sort of secret since at least the sixties.
>

I guess it depends on what is expected.
if it is intended to properly support x87, yes, probably.

if it is a last-ditch stop short of dropping it entirely, with it kept 
mostly so that old software keeps working, it may still be "better than 
nothing".

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

#59724

On 4/6/15 9:09 PM, BGB wrote:
> On 4/6/2015 5:41 PM, Robert Wessel wrote:
>> On Mon, 06 Apr 2015 16:30:14 -0500, BGB <cr88192@hotmail.com> wrote:
>>
>>> On 4/6/2015 12:38 PM, Robert Wessel wrote:

> then again, I guess I deal with vaguely similar dealing with things like
> GPIO on ARM devices, where you basically write bit-masks to various
> locations to set and clear the various output pins (*), and write
> bit-masks to set the mode of various pins (usually, between input,
> output, or sometimes a pin-specific special mode).
>
> *: writing a value to one location, any set bits will set the
> corresponding pin, and to another location, any set bits will clear the
> pin.
>
> now, as to why it couldn't behave more like normal memory, who knows?...

My experience with such registers are that they tend to be filled with a 
bunch of bits that you want to set/clear in response to changing 
conditions. Generally you want to be sure you don't mess up the value of 
the other bits. If you are dealing with multi-threaded code or the 
presence of interrupts that might want to also access those registers, 
you want to avoid needing to do a read-modify-write cycle, with the need 
to do something to make it atomic. This makes the bit set/clear 
operations the idea access method.

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

#59738

On 07/04/15 04:44, Richard Damon wrote:
> On 4/6/15 9:09 PM, BGB wrote:
>> On 4/6/2015 5:41 PM, Robert Wessel wrote:
>>> On Mon, 06 Apr 2015 16:30:14 -0500, BGB <cr88192@hotmail.com> wrote:
>>>
>>>> On 4/6/2015 12:38 PM, Robert Wessel wrote:
> 
>> then again, I guess I deal with vaguely similar dealing with things like
>> GPIO on ARM devices, where you basically write bit-masks to various
>> locations to set and clear the various output pins (*), and write
>> bit-masks to set the mode of various pins (usually, between input,
>> output, or sometimes a pin-specific special mode).
>>
>> *: writing a value to one location, any set bits will set the
>> corresponding pin, and to another location, any set bits will clear the
>> pin.
>>
>> now, as to why it couldn't behave more like normal memory, who knows?...
> 
> My experience with such registers are that they tend to be filled with a
> bunch of bits that you want to set/clear in response to changing
> conditions. Generally you want to be sure you don't mess up the value of
> the other bits. If you are dealing with multi-threaded code or the
> presence of interrupts that might want to also access those registers,
> you want to avoid needing to do a read-modify-write cycle, with the need
> to do something to make it atomic. This makes the bit set/clear
> operations the idea access method.
> 

That is one reason for the set/clear registers.  Another is speed - a
write operation can be pipelined, and passed onto the slower peripheral
bus while the cpu continues on other operations, while a RMW cycle is
much slower.

The use of set/clear registers is /an/ ideal access method, not /the/
ideal access method.  There is another good method that is also
supported by ARM Cortex microcontrollers - bitbanding regions where a
block of memory is mapped into a region that is 32 times the size, with
each 32-bit word in this region mapping to a single bit in the static
ram or peripheral address space.  Thus each bit of a GPIO register has
its own unique uint32_t* address, and you can use this region to read or
write individual bits.  Whether you want to use the set/clear registers
or the bit-banding region often depends on whether you want to access
many bits simultaneously, or just the one bit.

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

#59690

On Monday, April 6, 2015 at 12:06:26 AM UTC-7, robert...@yahoo.com wrote:
> On Sun, 5 Apr 2015 23:39:16 -0700 (PDT), Weng Tianxiang
> <wtxwtx@gmail.com> wrote:
> 
> >On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
> >> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
> >> <wtxwtx@gmail.com> wrote:
> >> 
> >> >Hi, 
> >> >Does each core of 8-core Intel processor has an independent floating X87 unit? 
> >> >
> >> >Here are some texts from Intel latest datasheet: 
> >> >
> >> >Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
> >> >Datasheet - Volume 1 of 2 
> >> >
> >> >Processor Feature Details 
> >> >*Up to 8 execution cores 
> >> >*Each core supports two threads (Intel(R) Hyper-Threading Technology) 
> >> >*32 KB instruction and 32 KB data first-level cache (L1) for each core 
> >> >*256 KB shared instruction/data mid-level (L2) cache for each core 
> >> >*Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
> >> >
> >> >5.2 X87 FPU INSTRUCTIONS 
> >> >The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
> >> >
> >> >These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
> >> >
> >> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
> >> >
> >> >Am I right or not? 
> >> >
> >> >Is there anyone who has real experiences with X87 FPU unit? 
> >> 
> >> 
> >> 
> >> All current Intel x86s have the FPU on each core.  Some recent AMD
> >> processors have had an FPU shared between two cores.
> >
> >Robert,
> >Thank you for your reply.
> >
> >The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
> >
> >>The x87 FPU instructions are executed by the processor's x87 FPU. 
> >
> >Where do you know "All current Intel x86s have the FPU on each core"?
> 
> 
> The architectural documents specify nothing at all about the location
> of the FPUs.  They describe its function, not its implementation.  For
> all the architectural documents care, the CPU could be emailing a
> server in Wyoming to get FPU operations performed.  They're considered
> somewhat separately for historical reasons - pre-486, the FPU was
> actually a separate chip, and often not included in a system (even on
> 486s they were often not included, but the FPU was on the processor
> chip).
> 
> If you want to know how it's implemented, you need to look at some of
> the implementation details reveal by Intel, often at venues like Hot
> Chips, or look at one of the micro-architectural overview like this
> one:
> 
> http://www.realworldtech.com/haswell-cpu/
> 
> There is, of course, nothing to prevent Intel from building a CPU
> tomorrow with an FPU shared between cores (after all AMD already does
> that), but latency issues and the modest size of the scalar FPU makes
> it only a modest win.  In AMD's case, they shared the entire FPU (x87,
> MMX, SSE, etc.) between cores.  A complication in any sort of shared
> scheme is that all the cores sharing the FPU need their own set of
> registers and such.
> 
> For just the x87, a bunch of what's needed for the x87 is needed
> anyway for SSE support, so separating just the x87 support is really
> unlikely to be worthwhile.  If Intel decided to depreciate x87
> support, I suspect it would be by reducing most of the x87
> instructions to microcode, which did most of the work under the hood
> on the SSE hardware - wherever that hardware might be - but it still
> wouldn't likely be moved out by itself).

Hi Robert, 

Very good, informative and experienced comment! I appreciate it very much.

But you still didn't mention where your statement "All current Intel x86s have the FPU on each core" comes from.

Weng

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

#59696

On Mon, 6 Apr 2015 08:04:27 -0700 (PDT), Weng Tianxiang
<wtxwtx@gmail.com> wrote:

>On Monday, April 6, 2015 at 12:06:26 AM UTC-7, robert...@yahoo.com wrote:
>> On Sun, 5 Apr 2015 23:39:16 -0700 (PDT), Weng Tianxiang
>> <wtxwtx@gmail.com> wrote:
>> 
>> >On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>> >> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>> >> <wtxwtx@gmail.com> wrote:
>> >> 
>> >> >Hi, 
>> >> >Does each core of 8-core Intel processor has an independent floating X87 unit? 
>> >> >
>> >> >Here are some texts from Intel latest datasheet: 
>> >> >
>> >> >Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
>> >> >Datasheet - Volume 1 of 2 
>> >> >
>> >> >Processor Feature Details 
>> >> >*Up to 8 execution cores 
>> >> >*Each core supports two threads (Intel(R) Hyper-Threading Technology) 
>> >> >*32 KB instruction and 32 KB data first-level cache (L1) for each core 
>> >> >*256 KB shared instruction/data mid-level (L2) cache for each core 
>> >> >*Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
>> >> >
>> >> >5.2 X87 FPU INSTRUCTIONS 
>> >> >The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>> >> >
>> >> >These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
>> >> >
>> >> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
>> >> >
>> >> >Am I right or not? 
>> >> >
>> >> >Is there anyone who has real experiences with X87 FPU unit? 
>> >> 
>> >> 
>> >> 
>> >> All current Intel x86s have the FPU on each core.  Some recent AMD
>> >> processors have had an FPU shared between two cores.
>> >
>> >Robert,
>> >Thank you for your reply.
>> >
>> >The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
>> >
>> >>The x87 FPU instructions are executed by the processor's x87 FPU. 
>> >
>> >Where do you know "All current Intel x86s have the FPU on each core"?
>> 
>> 
>> The architectural documents specify nothing at all about the location
>> of the FPUs.  They describe its function, not its implementation.  For
>> all the architectural documents care, the CPU could be emailing a
>> server in Wyoming to get FPU operations performed.  They're considered
>> somewhat separately for historical reasons - pre-486, the FPU was
>> actually a separate chip, and often not included in a system (even on
>> 486s they were often not included, but the FPU was on the processor
>> chip).
>> 
>> If you want to know how it's implemented, you need to look at some of
>> the implementation details reveal by Intel, often at venues like Hot
>> Chips, or look at one of the micro-architectural overview like this
>> one:
>> 
>> http://www.realworldtech.com/haswell-cpu/
>> 
>> There is, of course, nothing to prevent Intel from building a CPU
>> tomorrow with an FPU shared between cores (after all AMD already does
>> that), but latency issues and the modest size of the scalar FPU makes
>> it only a modest win.  In AMD's case, they shared the entire FPU (x87,
>> MMX, SSE, etc.) between cores.  A complication in any sort of shared
>> scheme is that all the cores sharing the FPU need their own set of
>> registers and such.
>> 
>> For just the x87, a bunch of what's needed for the x87 is needed
>> anyway for SSE support, so separating just the x87 support is really
>> unlikely to be worthwhile.  If Intel decided to depreciate x87
>> support, I suspect it would be by reducing most of the x87
>> instructions to microcode, which did most of the work under the hood
>> on the SSE hardware - wherever that hardware might be - but it still
>> wouldn't likely be moved out by itself).
>
>Hi Robert, 
>
>Very good, informative and experienced comment! I appreciate it very much.
>
>But you still didn't mention where your statement "All current Intel x86s have the FPU on each core" comes from.


To some approximation, I've read the documents I mentioned for Intel's
current CPUs.

But the real question is why do you care?  A shared FPU would likely
have some performance implications (it certainly does in AMD's case!),
but that would be reflected in the optimization manual.  But other
than performance, the actual implementation is pretty much irrelevant
to you.

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

#59701

Weng Tianxiang wrote:

> 
> But you still didn't mention where your statement 
> "All current Intel x86s have the FPU on each core" comes from.
> 
> Weng

Find a counterexample, then you win.

*******

Even this thing has an FPU per core. All 61 cores.

https://software.intel.com/en-us/articles/intel-xeon-phi-coprocessor-codename-knights-corner

When floating point performance does not matter,
floating point instruction mix is 0% of all
running code, then the FPU can be shared over
many cores. As long as the competition (NVidia
in that case) has good floating point performance,
then extensive FPU units must be included in your
product too.

There are undoubtedly 8 bit embedded processors,
which are integer only. No FPU at all. But do we
care ? We're not doing our income taxes with them,
and those processors turn our light bulbs on and off.

    Paul

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

#59713

On 4/6/2015 1:52 PM, Paul wrote:
> Weng Tianxiang wrote:
>
>>
>> But you still didn't mention where your statement "All current Intel
>> x86s have the FPU on each core" comes from.
>>
>> Weng
>
> Find a counterexample, then you win.
>
> *******
>
> Even this thing has an FPU per core. All 61 cores.
>
> https://software.intel.com/en-us/articles/intel-xeon-phi-coprocessor-codename-knights-corner
>
>
> When floating point performance does not matter,
> floating point instruction mix is 0% of all
> running code, then the FPU can be shared over
> many cores. As long as the competition (NVidia
> in that case) has good floating point performance,
> then extensive FPU units must be included in your
> product too.
>
> There are undoubtedly 8 bit embedded processors,
> which are integer only. No FPU at all. But do we
> care ? We're not doing our income taxes with them,
> and those processors turn our light bulbs on and off.
>

actually, you have a lot of embedded 32-bit processors which are integer 
only (not just the 8-bit ones).

this is the case, for example, with most ARM Cortex-M processors.

even if you do have an FPU, you may not want to use it if it can be 
avoided (as its performance still sucks), or only 'float' is really 
usable (and its 'double' performance may be downright awful in comparison).


the general solution to a lot of this is using fixed point.

yes, you can also do things like real-time audio and video compression 
and decompression and similar using only fixed-point as well (and on 
processors still running in MHz territory).

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

#59691

Weng Tianxiang wrote:
> On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>> <wtxwtx@gmail.com> wrote:
>>
>>> Hi, 
>>> Does each core of 8-core Intel processor has an independent floating X87 unit? 
>>>
>>> Here are some texts from Intel latest datasheet: 
>>>
>>> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
>>> Datasheet - Volume 1 of 2 
>>>
>>> Processor Feature Details 
>>> *Up to 8 execution cores 
>>> *Each core supports two threads (Intel(R) Hyper-Threading Technology) 
>>> *32 KB instruction and 32 KB data first-level cache (L1) for each core 
>>> *256 KB shared instruction/data mid-level (L2) cache for each core 
>>> *Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
>>>
>>> 5.2 X87 FPU INSTRUCTIONS 
>>> The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>>>
>>> These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
>>>
>> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
>>> Am I right or not? 
>>>
>>> Is there anyone who has real experiences with X87 FPU unit? 
>>
>>
>> All current Intel x86s have the FPU on each core.  Some recent AMD
>> processors have had an FPU shared between two cores.
> 
> Robert,
> Thank you for your reply.
> 
> The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
> 
>> The x87 FPU instructions are executed by the processor's x87 FPU. 
> 
> Where do you know "All current Intel x86s have the FPU on each core"?
> 
> Weng

Look at a few block diagrams. What do you notice.
FPU sitting there next to Integer ALU. Even the
relatively new chip, the one in the last article.

http://www.tomshardware.com/reviews/good-newbie,466-3.html

http://www.bit-tech.net/hardware/cpus/2006/07/14/intel_core_2_duo_processors/4

http://www.itproportal.com/2013/05/08/a-closer-look-at-silvermont-is-intel-finally-ready-to-destroy-arm/

That's the Intel approach.

AMD Bulldozer is slightly different. The question here,
is whether you consider this to be another form of hyperthreading
(just sliced slightly differently), or whether it really
counts as "two cores" in the first block diagram.

http://en.wikipedia.org/wiki/Bulldozer_(microarchitecture)

    (More like a single core, with double the integer units.)

    http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG/586px-AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG

    (Eight cores or four cores ? You decide.)

    http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/AMD_Bulldozer_block_diagram_(8_core_CPU).PNG/727px-AMD_Bulldozer_block_diagram_(8_core_CPU).PNG

In any case, you do not stick an FPU way off to the side of
all the cores and "share" it. The performance would suck.
That only worked when a CPU ran at 5MHz or 8MHz. There
was little penalty, because everything was slow back in
those days.

HTH,
    Paul

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

#59697

On Mon, 06 Apr 2015 11:11:05 -0400, Paul <nospam@needed.com> wrote:

>Weng Tianxiang wrote:
>> On Sunday, April 5, 2015 at 8:34:32 PM UTC-7, robert...@yahoo.com wrote:
>>> On Sun, 5 Apr 2015 06:50:49 -0700 (PDT), Weng Tianxiang
>>> <wtxwtx@gmail.com> wrote:
>>>
>>>> Hi, 
>>>> Does each core of 8-core Intel processor has an independent floating X87 unit? 
>>>>
>>>> Here are some texts from Intel latest datasheet: 
>>>>
>>>> Intel(R) Core(tm) i7 Processor Family for LGA2011-v3 Socket 
>>>> Datasheet - Volume 1 of 2 
>>>>
>>>> Processor Feature Details 
>>>> *Up to 8 execution cores 
>>>> *Each core supports two threads (Intel(R) Hyper-Threading Technology) 
>>>> *32 KB instruction and 32 KB data first-level cache (L1) for each core 
>>>> *256 KB shared instruction/data mid-level (L2) cache for each core 
>>>> *Up to 15 MB last level cache (LLC): up to 2.5 MB per core instruction/data last level cache (LLC), shared among all cores. 
>>>>
>>>> 5.2 X87 FPU INSTRUCTIONS 
>>>> The x87 FPU instructions are executed by the processor's x87 FPU. These instructions operate on floating-point, integer, and binary-coded decimal (BCD) operands. For more detail on x87 FPU instructions, see Chapter 8, "Programming with the x87 FPU."
>>>>
>>>> These instructions are divided into the following subgroups: data transfer, load constants, and FPU control instructions. 
>>>>
>>> >From above text I have a feeling that all 8 execution cores share the same X87 FPU unit. 
>>>> Am I right or not? 
>>>>
>>>> Is there anyone who has real experiences with X87 FPU unit? 
>>>
>>>
>>> All current Intel x86s have the FPU on each core.  Some recent AMD
>>> processors have had an FPU shared between two cores.
>> 
>> Robert,
>> Thank you for your reply.
>> 
>> The following statement comes from the 5th processor document and it doesn't mention the core X87, but says the processor's x87 FPU!!!
>> 
>>> The x87 FPU instructions are executed by the processor's x87 FPU. 
>> 
>> Where do you know "All current Intel x86s have the FPU on each core"?
>> 
>> Weng
>
>Look at a few block diagrams. What do you notice.
>FPU sitting there next to Integer ALU. Even the
>relatively new chip, the one in the last article.
>
>http://www.tomshardware.com/reviews/good-newbie,466-3.html
>
>http://www.bit-tech.net/hardware/cpus/2006/07/14/intel_core_2_duo_processors/4
>
>http://www.itproportal.com/2013/05/08/a-closer-look-at-silvermont-is-intel-finally-ready-to-destroy-arm/
>
>That's the Intel approach.
>
>AMD Bulldozer is slightly different. The question here,
>is whether you consider this to be another form of hyperthreading
>(just sliced slightly differently), or whether it really
>counts as "two cores" in the first block diagram.
>
>http://en.wikipedia.org/wiki/Bulldozer_(microarchitecture)
>
>    (More like a single core, with double the integer units.)
>
>    http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG/586px-AMD_Bulldozer_block_diagram_(CPU_core_bloack).PNG
>
>    (Eight cores or four cores ? You decide.)
>
>    http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/AMD_Bulldozer_block_diagram_(8_core_CPU).PNG/727px-AMD_Bulldozer_block_diagram_(8_core_CPU).PNG
>
>In any case, you do not stick an FPU way off to the side of
>all the cores and "share" it. The performance would suck.
>That only worked when a CPU ran at 5MHz or 8MHz. There
>was little penalty, because everything was slow back in
>those days.


Case in point is the UltraSPARC T1 ("Niagara").  They shared a single
FPU between eight cores.  And yes, FP performance basically sucked.

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

#59715

On 06-Apr-15 12:47, Robert Wessel wrote:
> On Mon, 06 Apr 2015 11:11:05 -0400, Paul <nospam@needed.com> wrote:
>> In any case, you do not stick an FPU way off to the side of
>> all the cores and "share" it. The performance would suck. That only
>> worked when a CPU ran at 5MHz or 8MHz. There was little penalty,
>> because everything was slow back in those days.
> 
> Case in point is the UltraSPARC T1 ("Niagara").  They shared a
> single FPU between eight cores.  And yes, FP performance basically
> sucked.

Niagara was designed for a specific market (database and web servers)
where FP performance is mostly irrelevant; the FPU probably spends most
of its time powered off completely, only waking up when someone runs
server performance reports and such.  They probably could have left it
out completely and relied on software emulation instead.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#59735

On Mon, 06 Apr 2015 17:15:50 -0500, Stephen Sprunk
<stephen@sprunk.org> wrote:

>On 06-Apr-15 12:47, Robert Wessel wrote:
>> On Mon, 06 Apr 2015 11:11:05 -0400, Paul <nospam@needed.com> wrote:
>>> In any case, you do not stick an FPU way off to the side of
>>> all the cores and "share" it. The performance would suck. That only
>>> worked when a CPU ran at 5MHz or 8MHz. There was little penalty,
>>> because everything was slow back in those days.
>> 
>> Case in point is the UltraSPARC T1 ("Niagara").  They shared a
>> single FPU between eight cores.  And yes, FP performance basically
>> sucked.
>
>Niagara was designed for a specific market (database and web servers)
>where FP performance is mostly irrelevant; the FPU probably spends most
>of its time powered off completely, only waking up when someone runs
>server performance reports and such.  They probably could have left it
>out completely and relied on software emulation instead.


OTOH, it was a small bit of the chip (1/3 to 1/2 the size of a single
core) and would have been far faster than emulation on a single core.
Quite possibly total throughput on all eight cores for emulation could
have been almost as fast, but on the (valid) assumption that FP is
relatively rare in server code, it still makes sense to provide decent
performance when it does show up - Niagara's cores were pretty darn
slow to begin with, hitting even a modest patch of FP would have been
really slow if it would have had to drop to emulation.  And so long as
you don't get too many cores hitting patches of FP at once, it works
fairly well.

And a lot of web server workloads, while not FP intensive, still
execute a reasonable amount of FP - most of the scripting languages
that would run there pretty much make doubles the default numeric
type.

As always there's a tradeoff.  Would the performance benefit from
making the cores 1/24th to 1/16th larger have been bigger than the
performance benefit of the shared FPU?

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

#59739

Robert Wessel wrote:
> On Mon, 06 Apr 2015 17:15:50 -0500, Stephen Sprunk
> <stephen@sprunk.org> wrote:
>
>> On 06-Apr-15 12:47, Robert Wessel wrote:
>>> On Mon, 06 Apr 2015 11:11:05 -0400, Paul <nospam@needed.com> wrote:
>>>> In any case, you do not stick an FPU way off to the side of
>>>> all the cores and "share" it. The performance would suck. That only
>>>> worked when a CPU ran at 5MHz or 8MHz. There was little penalty,
>>>> because everything was slow back in those days.
>>>
>>> Case in point is the UltraSPARC T1 ("Niagara").  They shared a
>>> single FPU between eight cores.  And yes, FP performance basically
>>> sucked.
>>
>> Niagara was designed for a specific market (database and web servers)
>> where FP performance is mostly irrelevant; the FPU probably spends most
>> of its time powered off completely, only waking up when someone runs
>> server performance reports and such.  They probably could have left it
>> out completely and relied on software emulation instead.
>
>
> OTOH, it was a small bit of the chip (1/3 to 1/2 the size of a single
> core) and would have been far faster than emulation on a single core.
> Quite possibly total throughput on all eight cores for emulation could
> have been almost as fast, but on the (valid) assumption that FP is
> relatively rare in server code, it still makes sense to provide decent
> performance when it does show up - Niagara's cores were pretty darn
> slow to begin with, hitting even a modest patch of FP would have been
> really slow if it would have had to drop to emulation.  And so long as
> you don't get too many cores hitting patches of FP at once, it works
> fairly well.
>
> And a lot of web server workloads, while not FP intensive, still
> execute a reasonable amount of FP - most of the scripting languages
> that would run there pretty much make doubles the default numeric
> type.
>
> As always there's a tradeoff.  Would the performance benefit from
> making the cores 1/24th to 1/16th larger have been bigger than the
> performance benefit of the shared FPU?

Many lessons have been learned since the T1.  The new processors (T5s) 
clock three times faster and have one FPU per core.  Each core can 
support 128 threads, so there is still some sharing but given the high 
core count (16) there are plenty to go round!

-- 
Ian Collins

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

#59764

On 07-Apr-15 04:19, Ian Collins wrote:
> Robert Wessel wrote:
>> Stephen Sprunk <stephen@sprunk.org> wrote:
>>> Niagara was designed for a specific market (database and web
>>> servers) where FP performance is mostly irrelevant; the FPU
>>> probably spends most of its time powered off completely, only
>>> waking up when someone runs server performance reports and such.
>>> They probably could have left it out completely and relied on
>>> software emulation instead.
>> 
>> OTOH, it was a small bit of the chip (1/3 to 1/2 the size of a
>> single core) and would have been far faster than emulation on a
>> single core. ...
>> 
>> And a lot of web server workloads, while not FP intensive, still 
>> execute a reasonable amount of FP - most of the scripting
>> languages that would run there pretty much make doubles the default
>> numeric type. ...
> 
> Many lessons have been learned since the T1.  The new processors
> (T5s) clock three times faster and have one FPU per core.  Each core
> can support 128 threads, so there is still some sharing but given the
> high core count (16) there are plenty to go round!

Still, instead of 32 threads (4 per core) sharing an FPU, now they have
128 threads sharing each FPU.

The main lesson is that in such workloads, most threads spend most of
their time stalled due to pointer chasing and cache misses, which is why
they need 128 threads per core just to keep the ALUs (and even FPU)
busy, especially as clock rates increase and memory gets even further
away than it already was for the T1.

I'd love to see an x86 chip with such a design for similar workloads,
but Intel doesn't seem interested in taking SMT past 2 threads per core,
and AMD doesn't seem interested in SMT at all.

S


-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

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

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

csiph-web