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

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

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? 

Thank you. 

Weng 

[toc] | [next] | [standalone]

#59621

On 05/04/2015 15:50, Weng Tianxiang wrote:

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

comp.lang.c discusses the C programming language. Your question
is waaay off-topic. The comp.arch newsgroup might help you.

This in-depth review answers your question:
http://www.realworldtech.com/haswell-cpu/

And x87 is obsolete.

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

#59624

On Sun, 05 Apr 2015 17:17:42 +0200
Noob <root@127.0.0.1> wrote:

> 
> And x87 is obsolete.
> 

Who said that?

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

#59629

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).

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

#59631

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?

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

#59635

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.


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.

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

#59637

W dniu niedziela, 5 kwietnia 2015 18:59:54 UTC+2 użytkownik BGB napisał:
> 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.
> 
> 
> 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.

not sure if this is microsoft who decides here or intel or who.. 
not sure also if they should deprecate or drop x87 of no, maybe they should.. bit hard to say
(some could say they could drop x64 at all and build something nicer)

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

#59645

On 4/5/2015 12:08 PM, fir wrote:
> W dniu niedziela, 5 kwietnia 2015 18:59:54 UTC+2 użytkownik BGB napisał:
>> 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.
>>
>>
>> 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.
>
> not sure if this is microsoft who decides here or intel or who..
> not sure also if they should deprecate or drop x87 of no, maybe they should.. bit hard to say
> (some could say they could drop x64 at all and build something nicer)
>

each party says something slightly different.


thought was, eventually it may go away.

but, this is unlikely in mainstream processors anytime soon, and would 
most likely happen first with embedded processors (more likely in a 
scenario where x86-64 and AArch64 are start trying to compete on price 
point to displace 32-bit ARM in lower-end phones and in 
consumer-electronics, vs at present competing more over high-end 
smartphones and netbooks and tablets).


this will probably be also about the time when you can get a reasonably 
cheap board with a 64-bit SoC on it for sticking in electronics 
projects, whereas ATM $15 or $20 can get you a board with a 32-bit 
processor (8/16 bit MCUs are cheaper, and are easier to get in 
self-contained DIP modules, but typically suffer from a severe lack of 
RAM, but some options come as small PCB's which can still be stuck into 
DIP sockets via pin-headers, and maybe secured with hot-glue).

or such...

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

#59730

On 05/04/15 20:17, BGB wrote:
> On 4/5/2015 12:08 PM, fir wrote:
>> W dniu niedziela, 5 kwietnia 2015 18:59:54 UTC+2 użytkownik BGB napisał:
>>> 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.
>>>
>>>
>>> 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.
>>
>> not sure if this is microsoft who decides here or intel or who..
>> not sure also if they should deprecate or drop x87 of no, maybe they
>> should.. bit hard to say
>> (some could say they could drop x64 at all and build something nicer)
>>
> 
> each party says something slightly different.
> 
> 
> thought was, eventually it may go away.
> 
> but, this is unlikely in mainstream processors anytime soon, and would
> most likely happen first with embedded processors (more likely in a
> scenario where x86-64 and AArch64 are start trying to compete on price
> point to displace 32-bit ARM in lower-end phones and in
> consumer-electronics, vs at present competing more over high-end
> smartphones and netbooks and tablets).
> 
> 
> this will probably be also about the time when you can get a reasonably
> cheap board with a 64-bit SoC on it for sticking in electronics
> projects, whereas ATM $15 or $20 can get you a board with a 32-bit
> processor (8/16 bit MCUs are cheaper, and are easier to get in
> self-contained DIP modules, but typically suffer from a severe lack of
> RAM, but some options come as small PCB's which can still be stuck into
> DIP sockets via pin-headers, and maybe secured with hot-glue).
> 

There are still a few hobby developers who see DIP as an advantage, but
as a proportion of devices, DIP chips or modules are negligible.  Small
developers often prefer wider pin spacing packages over the densest
devices, and they certainly prefer small pin counts, but few people
seriously use DIP any more.

And while 64-bit ARM may gradually replace 32-bit ARM in phones,
tablets, etc., it will not do so for small embedded devices where 32-bit
ARM Cortex-M is becoming dominant (and often significantly cheaper than
8/16-bit micros - you can get a 32-bit ARM device for under $0.50).

But for that sort of system, floating point precision or tight IEEE
compliance is usually irrelevant.  Single-precision 32-bit floats are
normally enough on the small proportion of systems that need floating
point at all.

> or such...
> 

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

#59762

On 4/7/2015 3:10 AM, David Brown wrote:
> On 05/04/15 20:17, BGB wrote:
>> On 4/5/2015 12:08 PM, fir wrote:
>>> W dniu niedziela, 5 kwietnia 2015 18:59:54 UTC+2 użytkownik BGB napisał:
>>>> 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.
>>>>
>>>>
>>>> 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.
>>>
>>> not sure if this is microsoft who decides here or intel or who..
>>> not sure also if they should deprecate or drop x87 of no, maybe they
>>> should.. bit hard to say
>>> (some could say they could drop x64 at all and build something nicer)
>>>
>>
>> each party says something slightly different.
>>
>>
>> thought was, eventually it may go away.
>>
>> but, this is unlikely in mainstream processors anytime soon, and would
>> most likely happen first with embedded processors (more likely in a
>> scenario where x86-64 and AArch64 are start trying to compete on price
>> point to displace 32-bit ARM in lower-end phones and in
>> consumer-electronics, vs at present competing more over high-end
>> smartphones and netbooks and tablets).
>>
>>
>> this will probably be also about the time when you can get a reasonably
>> cheap board with a 64-bit SoC on it for sticking in electronics
>> projects, whereas ATM $15 or $20 can get you a board with a 32-bit
>> processor (8/16 bit MCUs are cheaper, and are easier to get in
>> self-contained DIP modules, but typically suffer from a severe lack of
>> RAM, but some options come as small PCB's which can still be stuck into
>> DIP sockets via pin-headers, and maybe secured with hot-glue).
>>
>
> There are still a few hobby developers who see DIP as an advantage, but
> as a proportion of devices, DIP chips or modules are negligible.  Small
> developers often prefer wider pin spacing packages over the densest
> devices, and they certainly prefer small pin counts, but few people
> seriously use DIP any more.
>

for a hobbyist though, DIP is very useful when building custom (mostly 
one-off) boards by hand (using a lot of wire-wrap and soldering).

and DIP sockets are pretty useful when you want parts to be removable.


luckily, my projects tend to be big enough that I can have multiple boards.

for example, a small robot project of mine currently has 3 boards:
a Raspberry Pi;
a motor-interface board (has a few transistor H-bridges and similar on it);
a power-regulator board, which mostly has voltage-regulators, some 
diodes and capacitors, ... (its main thing is to supply 5v power for the 
RPi and the cameras and a few other things).

there is also some mostly glue-stuff done on a breadboard.


for another project, I may use a Raspberry Pi 2 (mostly for sake of it 
having a multi-core processor, so RT and non-RT stuff can coexist more 
peacefully).


but, the thought would be it would be nice if something along similar 
lines (capability wise) to a Raspberry Pi 2 could be crammed into a more 
compact package (though there is a RPi variant which fits into 
re-purposed SO-DIMM slots).



> And while 64-bit ARM may gradually replace 32-bit ARM in phones,
> tablets, etc., it will not do so for small embedded devices where 32-bit
> ARM Cortex-M is becoming dominant (and often significantly cheaper than
> 8/16-bit micros - you can get a 32-bit ARM device for under $0.50).
>

yeah.

an ARM Cortex-M is at this point a bit cheaper than, say, a PIC32 
device. though in quick searches, I had seen PIC32 devices with a wider 
temperature range than I have seen Cortex-M devices available for.


I suspect 64-bit could happen in micros, though probably a bit further 
in the future (currently nowhere near enough RAM in most of them to make 
this worthwhile).


> But for that sort of system, floating point precision or tight IEEE
> compliance is usually irrelevant.  Single-precision 32-bit floats are
> normally enough on the small proportion of systems that need floating
> point at all.
>

yeah.

most stuff can be done either with integer or fixed-point.

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

#59781

On 07/04/15 17:26, BGB wrote:
> On 4/7/2015 3:10 AM, David Brown wrote:
>> On 05/04/15 20:17, BGB wrote:
>>> On 4/5/2015 12:08 PM, fir wrote:
>>>> W dniu niedziela, 5 kwietnia 2015 18:59:54 UTC+2 użytkownik BGB
>>>> napisał:
>>>>> 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.
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> not sure if this is microsoft who decides here or intel or who..
>>>> not sure also if they should deprecate or drop x87 of no, maybe they
>>>> should.. bit hard to say
>>>> (some could say they could drop x64 at all and build something nicer)
>>>>
>>>
>>> each party says something slightly different.
>>>
>>>
>>> thought was, eventually it may go away.
>>>
>>> but, this is unlikely in mainstream processors anytime soon, and would
>>> most likely happen first with embedded processors (more likely in a
>>> scenario where x86-64 and AArch64 are start trying to compete on price
>>> point to displace 32-bit ARM in lower-end phones and in
>>> consumer-electronics, vs at present competing more over high-end
>>> smartphones and netbooks and tablets).
>>>
>>>
>>> this will probably be also about the time when you can get a reasonably
>>> cheap board with a 64-bit SoC on it for sticking in electronics
>>> projects, whereas ATM $15 or $20 can get you a board with a 32-bit
>>> processor (8/16 bit MCUs are cheaper, and are easier to get in
>>> self-contained DIP modules, but typically suffer from a severe lack of
>>> RAM, but some options come as small PCB's which can still be stuck into
>>> DIP sockets via pin-headers, and maybe secured with hot-glue).
>>>
>>
>> There are still a few hobby developers who see DIP as an advantage, but
>> as a proportion of devices, DIP chips or modules are negligible.  Small
>> developers often prefer wider pin spacing packages over the densest
>> devices, and they certainly prefer small pin counts, but few people
>> seriously use DIP any more.
>>
>
> for a hobbyist though, DIP is very useful when building custom (mostly
> one-off) boards by hand (using a lot of wire-wrap and soldering).
>
> and DIP sockets are pretty useful when you want parts to be removable.

That's the theory, and it is wildly over-estimated in importance.  Parts 
are seldom removed - certainly not the microcontroller.  It's true that 
some people insist on making life harder for themselves by trying to use 
DIP packages - resulting in bigger, slower, more expensive and more 
limited microcontrollers when they could have easily used something much 
better on a ready-made microcontroller board.  There are people who 
would rather spend days extra on an inferior system rather than spend a 
few extra pennies.  But as I said, such uses are extremely minor in the 
overall picture.

>
>
> luckily, my projects tend to be big enough that I can have multiple boards.
>
> for example, a small robot project of mine currently has 3 boards:
> a Raspberry Pi;
> a motor-interface board (has a few transistor H-bridges and similar on it);
> a power-regulator board, which mostly has voltage-regulators, some
> diodes and capacitors, ... (its main thing is to supply 5v power for the
> RPi and the cameras and a few other things).
>
> there is also some mostly glue-stuff done on a breadboard.
>
>
> for another project, I may use a Raspberry Pi 2 (mostly for sake of it
> having a multi-core processor, so RT and non-RT stuff can coexist more
> peacefully).
>
>
> but, the thought would be it would be nice if something along similar
> lines (capability wise) to a Raspberry Pi 2 could be crammed into a more
> compact package (though there is a RPi variant which fits into
> re-purposed SO-DIMM slots).
>
>
>
>> And while 64-bit ARM may gradually replace 32-bit ARM in phones,
>> tablets, etc., it will not do so for small embedded devices where 32-bit
>> ARM Cortex-M is becoming dominant (and often significantly cheaper than
>> 8/16-bit micros - you can get a 32-bit ARM device for under $0.50).
>>
>
> yeah.
>
> an ARM Cortex-M is at this point a bit cheaper than, say, a PIC32
> device. though in quick searches, I had seen PIC32 devices with a wider
> temperature range than I have seen Cortex-M devices available for.

It's a pity Microchip have made such a pig's breakfast with the PIC32 - 
it really spoiled the reputation of MIPS in the small microcontroller 
market.  It is a pointless device.  (But details here would be even more 
seriously off-topic in c.l.c.).

>
> I suspect 64-bit could happen in micros, though probably a bit further
> in the future (currently nowhere near enough RAM in most of them to make
> this worthwhile).

64-bit microcontrollers have been mainstream in particular parts of the 
embedded market for longer than they have been common on desktops.  But 
they are only used where they are /useful/ (typically high-end 
networking equipment and other communication devices, as well as 
audio/video processing).  And that is how it will continue to be - they 
will only become common in systems where it is useful to have more than 
4 GB address space, or more serious processing power.

>
>
>> But for that sort of system, floating point precision or tight IEEE
>> compliance is usually irrelevant.  Single-precision 32-bit floats are
>> normally enough on the small proportion of systems that need floating
>> point at all.
>>
>
> yeah.
>
> most stuff can be done either with integer or fixed-point.
>

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

#59782

On 07/04/2015 22:40, David Brown wrote:
> On 07/04/15 17:26, BGB wrote:

>> for a hobbyist though, DIP is very useful when building custom (mostly
>> one-off) boards by hand (using a lot of wire-wrap and soldering).
>>
>> and DIP sockets are pretty useful when you want parts to be removable.
>
> That's the theory, and it is wildly over-estimated in importance.  Parts
> are seldom removed - certainly not the microcontroller.

When I worked in hardware in the early 80s, we invariably used sockets. 
It made life easier not harder. The production PCBs were hand assembled 
and soldered, and it required less skill to insert sockets and solder 
than to find the right chips and plug them in the right way around. This 
was done later, and mistakes were easily rectified.

It was also easier to reuse ICs for any reason. (I worked mainly on 
experimental designs, where reuse was important, but also trying 
different specs of chips if it didn't work!). Anyway some packages 
(PLCC?) required a socket. Surface mount hadn't come in yet.

> It's true that
> some people insist on making life harder for themselves by trying to use
> DIP packages - resulting in bigger,

Bigger is good (especially now when I can barely see even the 0.1" 
spaced pins or whatever it was). I was soldering hand-wired prototypes 
(no PCB yet) with up to 150 DIPs on them and that was already very 
tight. (I never used wire-wrap and didn't like it.)

-- 
Bartc

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

#59783

On 08/04/15 00:06, Bartc wrote:
> On 07/04/2015 22:40, David Brown wrote:
>> On 07/04/15 17:26, BGB wrote:
>
>>> for a hobbyist though, DIP is very useful when building custom (mostly
>>> one-off) boards by hand (using a lot of wire-wrap and soldering).
>>>
>>> and DIP sockets are pretty useful when you want parts to be removable.
>>
>> That's the theory, and it is wildly over-estimated in importance.  Parts
>> are seldom removed - certainly not the microcontroller.
>
> When I worked in hardware in the early 80s, we invariably used sockets.
> It made life easier not harder. The production PCBs were hand assembled
> and soldered, and it required less skill to insert sockets and solder
> than to find the right chips and plug them in the right way around. This
> was done later, and mistakes were easily rectified.

That was all true at the time, but things have moved on a little since 
the early 80's...

People who are making serious PCB's use surface mount devices - 
equipment to solder them is not expensive (in a professional context) or 
difficult to use, until you are looking at very fine pitch or BGA 
packages.  People who are doing /successful/ hobby designs use 
ready-made boards for the microcontroller and surrounding base 
components (crystal, caps, special power supply chips, etc.) - often 
using "standard" boards like Aduino or Raspberry Pi's.  Then they will 
hand-make whatever else they need.

More serious enthusiasts have no problem soldering TQFP, SOIC, and even 
BGA devices using kitchen ovens and toasters - there are plenty of 
Youtube guides around.

>
> It was also easier to reuse ICs for any reason. (I worked mainly on
> experimental designs, where reuse was important, but also trying
> different specs of chips if it didn't work!). Anyway some packages
> (PLCC?) required a socket. Surface mount hadn't come in yet.
>
>> It's true that
>> some people insist on making life harder for themselves by trying to use
>> DIP packages - resulting in bigger,
>
> Bigger is good (especially now when I can barely see even the 0.1"
> spaced pins or whatever it was). I was soldering hand-wired prototypes
> (no PCB yet) with up to 150 DIPs on them and that was already very
> tight. (I never used wire-wrap and didn't like it.)
>

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

#59786

On 4/7/2015 6:23 PM, David Brown wrote:
> On 08/04/15 00:06, Bartc wrote:
>> On 07/04/2015 22:40, David Brown wrote:
>>> On 07/04/15 17:26, BGB wrote:
>>
>>>> for a hobbyist though, DIP is very useful when building custom (mostly
>>>> one-off) boards by hand (using a lot of wire-wrap and soldering).
>>>>
>>>> and DIP sockets are pretty useful when you want parts to be removable.
>>>
>>> That's the theory, and it is wildly over-estimated in importance.  Parts
>>> are seldom removed - certainly not the microcontroller.
>>
>> When I worked in hardware in the early 80s, we invariably used sockets.
>> It made life easier not harder. The production PCBs were hand assembled
>> and soldered, and it required less skill to insert sockets and solder
>> than to find the right chips and plug them in the right way around. This
>> was done later, and mistakes were easily rectified.
>
> That was all true at the time, but things have moved on a little since
> the early 80's...
>
> People who are making serious PCB's use surface mount devices -
> equipment to solder them is not expensive (in a professional context) or
> difficult to use, until you are looking at very fine pitch or BGA
> packages.  People who are doing /successful/ hobby designs use
> ready-made boards for the microcontroller and surrounding base
> components (crystal, caps, special power supply chips, etc.) - often
> using "standard" boards like Aduino or Raspberry Pi's.  Then they will
> hand-make whatever else they need.
>

some of my projects have used an RPi as the controller, with a lot of 
the special functionality on custom-built boards (mostly wire-wrap and 
similar, *).


possibly, more could be bought, but a lot is finding a good local minima 
WRT cost and effort, say, using an RPi may be good.


*: exact strategy depends a lot on how thick of wires I am using, which 
depends a lot on how much current the trace is running (a lot of these 
boards are for running motors and similar).

for example, 28, 24, and 20 AWG wire may be used differently:
28, run directly from post-to-post, wrapped on posts and soldered;
24, run on top of board, ran through holes and twisted to post and soldered;
20, run on top of board, bent over towards post and soldered;
16, run point to point, often on bottom of board (requires drilling to 
run on top of board), mostly used for power wiring.


> More serious enthusiasts have no problem soldering TQFP, SOIC, and even
> BGA devices using kitchen ovens and toasters - there are plenty of
> Youtube guides around.
>

I have seen videos of people using modded toaster-ovens for this.

part of the issue is that making custom PCBs is a bit more involved and 
expensive (and nasty, if one is using the acid-etch strategy).

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

#59784

On 4/7/2015 4:40 PM, David Brown wrote:
> On 07/04/15 17:26, BGB wrote:
>> On 4/7/2015 3:10 AM, David Brown wrote:
>>> On 05/04/15 20:17, BGB wrote:

>>
>> for a hobbyist though, DIP is very useful when building custom (mostly
>> one-off) boards by hand (using a lot of wire-wrap and soldering).
>>
>> and DIP sockets are pretty useful when you want parts to be removable.
>
> That's the theory, and it is wildly over-estimated in importance.  Parts
> are seldom removed - certainly not the microcontroller.  It's true that
> some people insist on making life harder for themselves by trying to use
> DIP packages - resulting in bigger, slower, more expensive and more
> limited microcontrollers when they could have easily used something much
> better on a ready-made microcontroller board.  There are people who
> would rather spend days extra on an inferior system rather than spend a
> few extra pennies.  But as I said, such uses are extremely minor in the
> overall picture.
>

you may want to have the parts removable, as this allows reusing some of 
them if one builds a later board and doesn't have more of these parts 
on-hand.

whereas, if you solder the components, it is a lot more work to remove 
them later.

it also makes sense for parts which are more expensive. say, one has a 
$15 accelerometer, they probably don't want it permanently soldered down.

and, the chips may be a fair bit more expensive than the DIP sockets.


>>
>> yeah.
>>
>> an ARM Cortex-M is at this point a bit cheaper than, say, a PIC32
>> device. though in quick searches, I had seen PIC32 devices with a wider
>> temperature range than I have seen Cortex-M devices available for.
>
> It's a pity Microchip have made such a pig's breakfast with the PIC32 -
> it really spoiled the reputation of MIPS in the small microcontroller
> market.  It is a pointless device.  (But details here would be even more
> seriously off-topic in c.l.c.).
>

dunno.

never really looked that deeply into all this.


>>
>> I suspect 64-bit could happen in micros, though probably a bit further
>> in the future (currently nowhere near enough RAM in most of them to make
>> this worthwhile).
>
> 64-bit microcontrollers have been mainstream in particular parts of the
> embedded market for longer than they have been common on desktops.  But
> they are only used where they are /useful/ (typically high-end
> networking equipment and other communication devices, as well as
> audio/video processing).  And that is how it will continue to be - they
> will only become common in systems where it is useful to have more than
> 4 GB address space, or more serious processing power.
>

might become more common later, say if cost comes down that one ends up 
with many GBs of RAM "just because...".

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

#59794

On 08/04/15 03:16, BGB wrote:
> On 4/7/2015 4:40 PM, David Brown wrote:
>> On 07/04/15 17:26, BGB wrote:
>>> On 4/7/2015 3:10 AM, David Brown wrote:
>>>> On 05/04/15 20:17, BGB wrote:
> 
>>>
>>> for a hobbyist though, DIP is very useful when building custom (mostly
>>> one-off) boards by hand (using a lot of wire-wrap and soldering).
>>>
>>> and DIP sockets are pretty useful when you want parts to be removable.
>>
>> That's the theory, and it is wildly over-estimated in importance.  Parts
>> are seldom removed - certainly not the microcontroller.  It's true that
>> some people insist on making life harder for themselves by trying to use
>> DIP packages - resulting in bigger, slower, more expensive and more
>> limited microcontrollers when they could have easily used something much
>> better on a ready-made microcontroller board.  There are people who
>> would rather spend days extra on an inferior system rather than spend a
>> few extra pennies.  But as I said, such uses are extremely minor in the
>> overall picture.
>>
> 
> you may want to have the parts removable, as this allows reusing some of
> them if one builds a later board and doesn't have more of these parts
> on-hand.
> 
> whereas, if you solder the components, it is a lot more work to remove
> them later.
> 
> it also makes sense for parts which are more expensive. say, one has a
> $15 accelerometer, they probably don't want it permanently soldered down.
> 
> and, the chips may be a fair bit more expensive than the DIP sockets.
> 

I have been talking rather specifically about microcontrollers in DIP
packages, not DIP in general.  Yes, there are situations where DIP (and
similar) sockets and packages are still useful for hobby boards.  But
there is a huge difference between putting a $15 accelerometer in an
8-pin DIP socket and trying to handle an 80-pin microcontroller with a
socket.  Insistence on using a DIP package is what leads people to spend
$10 on brain-dead PIC devices, $50 (or whatever) for a debug interface,
and waste their time with crappy tools and a microcontroller that was
barely considered modern 30 years ago.

Alternatively, you could spend $20 on an evaluation board for a modern
microcontroller and get built-in debugging tools, modern development
suites (that compile /real/ C, rather than a limited subset with weird
extensions - getting back on topic!), and peripherals such as USB,
Ethernet, etc.  Or you could go a step up in processing power and
development convenience, but a step down in controllability and
determinism, with an embedded Linux card like the Pi.

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

#59823

On 4/8/2015 2:27 AM, David Brown wrote:
> On 08/04/15 03:16, BGB wrote:
>> On 4/7/2015 4:40 PM, David Brown wrote:
>>> On 07/04/15 17:26, BGB wrote:
>>>> On 4/7/2015 3:10 AM, David Brown wrote:
>>>>> On 05/04/15 20:17, BGB wrote:
>>
>>>>
>>>> for a hobbyist though, DIP is very useful when building custom (mostly
>>>> one-off) boards by hand (using a lot of wire-wrap and soldering).
>>>>
>>>> and DIP sockets are pretty useful when you want parts to be removable.
>>>
>>> That's the theory, and it is wildly over-estimated in importance.  Parts
>>> are seldom removed - certainly not the microcontroller.  It's true that
>>> some people insist on making life harder for themselves by trying to use
>>> DIP packages - resulting in bigger, slower, more expensive and more
>>> limited microcontrollers when they could have easily used something much
>>> better on a ready-made microcontroller board.  There are people who
>>> would rather spend days extra on an inferior system rather than spend a
>>> few extra pennies.  But as I said, such uses are extremely minor in the
>>> overall picture.
>>>
>>
>> you may want to have the parts removable, as this allows reusing some of
>> them if one builds a later board and doesn't have more of these parts
>> on-hand.
>>
>> whereas, if you solder the components, it is a lot more work to remove
>> them later.
>>
>> it also makes sense for parts which are more expensive. say, one has a
>> $15 accelerometer, they probably don't want it permanently soldered down.
>>
>> and, the chips may be a fair bit more expensive than the DIP sockets.
>>
>
> I have been talking rather specifically about microcontrollers in DIP
> packages, not DIP in general.  Yes, there are situations where DIP (and
> similar) sockets and packages are still useful for hobby boards.  But
> there is a huge difference between putting a $15 accelerometer in an
> 8-pin DIP socket and trying to handle an 80-pin microcontroller with a
> socket.  Insistence on using a DIP package is what leads people to spend
> $10 on brain-dead PIC devices, $50 (or whatever) for a debug interface,
> and waste their time with crappy tools and a microcontroller that was
> barely considered modern 30 years ago.
>

yeah, the lack of "good" micros in DIP packages had been noted before.
some people sell QFP to DIP adapters, but these tend to cost more than 
the ICs themselves.

so, yeah, this mostly leaves using premade boards for this.


> Alternatively, you could spend $20 on an evaluation board for a modern
> microcontroller and get built-in debugging tools, modern development
> suites (that compile /real/ C, rather than a limited subset with weird
> extensions - getting back on topic!), and peripherals such as USB,
> Ethernet, etc.  Or you could go a step up in processing power and
> development convenience, but a step down in controllability and
> determinism, with an embedded Linux card like the Pi.
>

yeah.

with the RPi, it is possible to get ok RT by setting the nice and 
priority levels to basically let the RT thread eat the CPU, and then use 
a custom scheduler (with pretty much everything going through this 
scheduler, running as a single big thread).

though, pretty much nothing else can run on the system at the same time 
as the RT thread (anything else is basically fairly slow and 
unresponsive, *2). likewise, Linux is set not to start X or similar.


the RPi2 is multi-core, so it should be possible to have a high-priority 
RT thread localized to one core, and then use other cores for high-level 
logic (and be able to get a little more done on it).


in general, I like having a full featured C, but some of the extensions 
can be convenient as well.


as-is, in my case, it is possible to run some high-level code in an 
interpreter/VM, where a VM was written which plays OK with the scheduler 
(I have recently been working a bit on the compiler for the VM, trying 
to get Quake working in it as an experiment, *1, which is revealing a 
lot of bugs...).

a cost of the VM is that it runs a lot slower than native, and competes 
with other "idle-time" work (I also do video-stream encoding and other 
things as idle-time tasks), but makes some sense for things which aren't 
particularly processor intensive.

basically, it runs in the time where there is a delay until any more 
tasks are scheduled to run in the FIFO scheduler, so needs to be able to 
run for a bounded number of microseconds (there is another round-robin 
style scheduler for idle-tasks).


*1: the language is not strictly standard C, but "close enough". kind of 
unimpressive though just how many bugs this has been shaking up. another 
issue was trying to fix up memory leaks in the compiler (where the 
compiler was running out of RAM before getting it compiled). so, yeah, I 
guess technically it is kind of a "piece of crap", but oh well...

in this VM, there is no good/convenient way to do native C -> VM calls, 
but for the use-case you don't really want to do this anyways (or call 
into any native C code which may block or otherwise cause a delay).

the VM is designed to try to avoid the introduction of delays. I have 
another version which could have both a lower memory footprint and 
better avoid delays, but would also run slower (it uses a direct 
interpreter, rather than by converting to threaded code).


a specialized AoT compiler could be better in terms of both speed and 
keeping delays under control, but would thus far be the most complicated 
option (would need to write a code generator to produce appropriate ARM 
code).

its main special feature then vs native C would be that code runs in a 
trampoline loop (and within explicit secondary execution contexts), 
which trades some performance for being able to more precisely control 
execution times (*2).


*2: and, the main reason I can't really use native OS threads:
the OS is very imprecise about delays.

say, it you want to have the code run again in, say, 20us, and try 
something like "usleep(20)", it doesn't work, and by the time "usleep()" 
returns, it may be 500us or more later...

hence, part of why the whole custom RT scheduler exists in the first place.

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

#59641

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.


> 
> 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.

> 

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

#59668

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.


>
>>
>> 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.

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

#59674

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.


>
>>
>>>
>>> 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.

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

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

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

csiph-web