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

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

What happened to short float?

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

Contents

  What happened to short float? Philipp Klaus Krause <pkk@spth.de> - 2018-01-17 17:21 +0100
    Re: What happened to short float? "James R. Kuyper" <jameskuyper@verizon.net> - 2018-01-17 11:42 -0500
      Re: What happened to short float? jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-02 23:08 +0100
        Re: What happened to short float? Jakob Bohm <jb-usenet@wisemo.com> - 2018-02-05 07:57 +0100
          Re: What happened to short float? jameskuyper@verizon.net - 2018-02-05 05:31 -0800
        Re: What happened to short float? Tim Prince <tprince@intelretiree.com> - 2018-02-05 08:55 -0500
          Re: What happened to short float? jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-05 15:46 +0100
          Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 01:29 +0100
            Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-07 16:59 -0800
              Re: What happened to short float? Philipp Klaus Krause <pkk@spth.de> - 2018-02-08 09:08 +0100
                Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-08 09:27 -0800
              Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 09:54 +0100
                Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-08 10:13 -0800
              Re: What happened to short float? jameskuyper@verizon.net - 2018-02-08 06:36 -0800
                Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 17:04 +0100
                  Re: What happened to short float? jameskuyper@verizon.net - 2018-02-08 08:56 -0800
                    Re: What happened to short float? scott@slp53.sl.home (Scott Lurndal) - 2018-02-08 17:23 +0000
                    Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 18:52 +0100
                      Re: What happened to short float? jameskuyper@verizon.net - 2018-02-08 11:27 -0800
                        Re: What happened to short float? GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-08 22:58 +0100
                Re: What happened to short float? Keith Thompson <kst-u@mib.org> - 2018-02-08 10:18 -0800
            Re: What happened to short float? Jakob Bohm <jb-usenet@wisemo.com> - 2018-02-08 18:59 +0100
              Re: What happened to short float? Robert Wessel <robertwessel2@yahoo.com> - 2018-02-08 16:22 -0600
                Re: What happened to short float? Jakob Bohm <jb-usenet@wisemo.com> - 2018-02-09 15:01 +0100
    Re: What happened to short float? Chad <cdalten@gmail.com> - 2018-01-17 09:12 -0800
    Re: What happened to short float? scott@slp53.sl.home (Scott Lurndal) - 2018-01-17 17:31 +0000
    Re: What happened to short float? jacobnavia <jacob@jacob.remcomp.fr> - 2018-01-17 19:52 +0100
      Re: What happened to short float? Philipp Klaus Krause <pkk@spth.de> - 2018-01-18 13:18 +0100
        Re: What happened to short float? bartc <bc@freeuk.com> - 2018-01-18 12:40 +0000

Page 2 of 2 — ← Prev page 1 [2]

#126449

jameskuyper@verizon.net writes:
> On Wednesday, February 7, 2018 at 8:00:05 PM UTC-5, Keith Thompson wrote:
>> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>> > On Mon, 5 Feb 2018 08:55:00 -0500
>> > Tim Prince <tprince@intelretiree.com> wrote:
>> >> On 2/2/2018 5:08 PM, jacobnavia wrote:
>> >> Perhaps there is little more to say.  The format has little attraction
>> >> for portable code, as many platforms can't implement it efficiently.
>> >
>> > Any IEEE 754 compliant hardware that supports the float type (aka single
>> > precision float) would be able to support the short float type (i.e.
>> > less or equal to single precision float).
>> 
>> Wouldn't you need extra code to convert between 16-bit and 32-bit
>> formats?  For normal values you'd need to do some bit-twiddling.
>> Special values like infinities, NaNs, subnormals, and so forth might
>> require some extra work (I haven't looked into the details).
>
> I'd expect that the characteristics of a new short float type would be
> specified in the same way as they are for float, double, and long
> double. The requirements in 5.2.4.2.2 on the numeric characteristics of
> floating point types set either maximum values, or minimum values, or
> minimums on the magnitude of the values - so there's nothing preventing
> float, for instance, from being an 80-bit floating point type. The same
> would therefore also be true of short float. I'd expect at least some
> implementations targeting a platform with no hardware support for a
> 16-bit type to use a 32-bit floating point type for short float.
>
> I've just reviewed the proposal, and it doesn't go into such details.

N2016 4.1 does say:

    Or, the platform may choose to not take any advantages of short
    float and represent it using float in both memory and registers.

("using the same representation as float" would be more precise.)

My comments still apply, but only to implementations that implement
short float as a 16-bit type (more generally as a type narrower than
float).

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

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

#126447

On 08/02/2018 01:29, GOTHIER Nathan wrote:
> On Mon, 5 Feb 2018 08:55:00 -0500
> Tim Prince <tprince@intelretiree.com> wrote:
> 
>> On 2/2/2018 5:08 PM, jacobnavia wrote:
>> Perhaps there is little more to say.  The format has little attraction
>> for portable code, as many platforms can't implement it efficiently.
>>
>> -- 
>> Tim Prince
> 
> Any IEEE 754 compliant hardware that supports the float type (aka single
> precision float) would be able to support the short float type (i.e.
> less or equal to single precision float).
> 
> Actually the AMD64 architecture FPU only computes 80-bit floats and
> the long double type is a synonym for the double or float types since
> they are internally the same thing.
> 

That's not exactly right.  The AMD64/x86_64 architecture, like its
IA32/x86_32 and IA16/x86_16 predecessors natively support long double
(80 bits, sometimes padded to 128 bits for alignment, limited support in
SIMD instructions), double (64 bit IEEE 754) and float (32 bit IEEE
754).  The newest CPU models also support half floats (16 bit IEEE 754).

However for most operations, the calculations are done on the full size
of the used floating point registers (such as 80 bit long double for the
classic x87 style registers, 64 bit double for the MMX, SSE and AVX
registers in double mode), with the smaller sizes only used for load
and store.  Some optimization guides suggest that AMD64 C compilers
should default to using the SSE 64 bit double registers instead
of the x87 80 bit long double registers, thus at least some C compilers
might decide to treat long double as an alias for double (64 bit)
instead of the higher precision 80 bit type.  However float (32 bit) is
a native type for which support has been enhanced even in the latest
processors (mostly in the form of vector instructions that operate on
float registers in larger vector 128 or 256 bit registers).

16 bit float is only hardware supported in some of the latest processors
(mostly those with AVX extensions), and would thus typically need a
hidden C library helper function to load/store to/from 32 bit float
registers on older CPUs.  I don't think there are any hardware 16 bit
float registers in any of the current x86 CPUs (except perhaps in the
on-die GPU).

Conversion between 32 bit float and 16 bit half float on CPUs without
hardware support can be done with a few integer register shifts and
adds, with or without overflow and NaN checks.


> The short float type implementation shouldn't be as hard as:
> 
> typedef float sflt_t;
> 
> Once more, the F16C instruction set enables to convert single precision
> floats to half precision floats for storage purpose. Thus, the
> implementation shouldn't be as hard as:
> 
> typedef char half_t[2];
> typedef half_t sflt_t;
> 


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

#126465

On Thu, 8 Feb 2018 18:59:36 +0100, Jakob Bohm <jb-usenet@wisemo.com>
wrote:

>On 08/02/2018 01:29, GOTHIER Nathan wrote:
>> On Mon, 5 Feb 2018 08:55:00 -0500
>> Tim Prince <tprince@intelretiree.com> wrote:
>> 
>>> On 2/2/2018 5:08 PM, jacobnavia wrote:
>>> Perhaps there is little more to say.  The format has little attraction
>>> for portable code, as many platforms can't implement it efficiently.
>>>
>>> -- 
>>> Tim Prince
>> 
>> Any IEEE 754 compliant hardware that supports the float type (aka single
>> precision float) would be able to support the short float type (i.e.
>> less or equal to single precision float).
>> 
>> Actually the AMD64 architecture FPU only computes 80-bit floats and
>> the long double type is a synonym for the double or float types since
>> they are internally the same thing.
>> 
>
>That's not exactly right.  The AMD64/x86_64 architecture, like its
>IA32/x86_32 and IA16/x86_16 predecessors natively support long double
>(80 bits, sometimes padded to 128 bits for alignment, limited support in
>SIMD instructions), double (64 bit IEEE 754) and float (32 bit IEEE
>754).  The newest CPU models also support half floats (16 bit IEEE 754).
>
>However for most operations, the calculations are done on the full size
>of the used floating point registers (such as 80 bit long double for the
>classic x87 style registers, 64 bit double for the MMX, SSE and AVX
>registers in double mode), with the smaller sizes only used for load
>and store.


That's not correct.  SSE2 scalar instructions operate in the specified
precision.  Thus you have MULSS for multiplying two (scalar) singles,
and MULSD for doubles.  Since SSE2 is a baseline for x86-64, and the
FPU instructions are not really part of anyones ABI, almost all x86-64
code uses the SSE2 instructions for FP.

The above does not apply to compilers supporting 80-bit long doubles,
those all go back to the FPU.

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

#126475

On 08/02/2018 23:22, Robert Wessel wrote:
> On Thu, 8 Feb 2018 18:59:36 +0100, Jakob Bohm <jb-usenet@wisemo.com>
> wrote:
> 
>> On 08/02/2018 01:29, GOTHIER Nathan wrote:
>>> On Mon, 5 Feb 2018 08:55:00 -0500
>>> Tim Prince <tprince@intelretiree.com> wrote:
>>>
>>>> On 2/2/2018 5:08 PM, jacobnavia wrote:
>>>> Perhaps there is little more to say.  The format has little attraction
>>>> for portable code, as many platforms can't implement it efficiently.
>>>>
>>>> -- 
>>>> Tim Prince
>>>
>>> Any IEEE 754 compliant hardware that supports the float type (aka single
>>> precision float) would be able to support the short float type (i.e.
>>> less or equal to single precision float).
>>>
>>> Actually the AMD64 architecture FPU only computes 80-bit floats and
>>> the long double type is a synonym for the double or float types since
>>> they are internally the same thing.
>>>
>>
>> That's not exactly right.  The AMD64/x86_64 architecture, like its
>> IA32/x86_32 and IA16/x86_16 predecessors natively support long double
>> (80 bits, sometimes padded to 128 bits for alignment, limited support in
>> SIMD instructions), double (64 bit IEEE 754) and float (32 bit IEEE
>> 754).  The newest CPU models also support half floats (16 bit IEEE 754).
>>
>> However for most operations, the calculations are done on the full size
>> of the used floating point registers (such as 80 bit long double for the
>> classic x87 style registers, 64 bit double for the MMX, SSE and AVX
>> registers in double mode), with the smaller sizes only used for load
>> and store.
> 
> 
> That's not correct.  SSE2 scalar instructions operate in the specified
> precision.  Thus you have MULSS for multiplying two (scalar) singles,
> and MULSD for doubles.  Since SSE2 is a baseline for x86-64, and the
> FPU instructions are not really part of anyones ABI, almost all x86-64
> code uses the SSE2 instructions for FP.
> 
> The above does not apply to compilers supporting 80-bit long doubles,
> those all go back to the FPU.
> 

I already wrote that in the part you snipped.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

#125449

On Wednesday, January 17, 2018 at 8:22:07 AM UTC-8, Philipp Klaus Krause wrote:
> At the 2016 London meeting of WG14, adding a new short float type
> (N2016) was discussed, and there was a clear consensus to move forward.
> 
> What has happened about short float since?

It grew up to become a tall one?

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

#125451

Philipp Klaus Krause <pkk@spth.de> writes:
>At the 2016 London meeting of WG14, adding a new short float type
>(N2016) was discussed, and there was a clear consensus to move forward.
>
>What has happened about short float since?
>

FP16 (16-bit floating point) is popular amongst the machine
learning crowd, but more in the context of
SIMD vectors.

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

#125454

Le 17/01/2018 à 17:21, Philipp Klaus Krause a écrit :
> At the 2016 London meeting of WG14, adding a new short float type
> (N2016) was discussed, and there was a clear consensus to move forward.
> 
> What has happened about short float since?
> 
> Philipp
> 
lcc hasn't implemented them because of time constraints.

They are a memory only format. The x86 transforms them on floats on 
reading them from RAM. The same for ARM.

They reduce the size of the data at the expense of precision. For many 
applications that can be a bonus, it depends.

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

#125468

Am 17.01.2018 um 19:52 schrieb jacobnavia:
> Le 17/01/2018 à 17:21, Philipp Klaus Krause a écrit :
>> At the 2016 London meeting of WG14, adding a new short float type
>> (N2016) was discussed, and there was a clear consensus to move forward.
>>
>> What has happened about short float since?
>>
>> Philipp
>>
> lcc hasn't implemented them because of time constraints.
> 
> They are a memory only format. The x86 transforms them on floats on
> reading them from RAM. The same for ARM.
> 
> They reduce the size of the data at the expense of precision. For many
> applications that can be a bonus, it depends.
> 

I'm somewhat interested in them, since their implementation could be
cosiderably faster than float/double on machines without hardware
support for floating-point operations. Typical examples would be most
8-bit µCs.

Philipp

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

#125469

On 18/01/2018 12:18, Philipp Klaus Krause wrote:
> Am 17.01.2018 um 19:52 schrieb jacobnavia:
>> Le 17/01/2018 à 17:21, Philipp Klaus Krause a écrit :
>>> At the 2016 London meeting of WG14, adding a new short float type
>>> (N2016) was discussed, and there was a clear consensus to move forward.
>>>
>>> What has happened about short float since?
>>>
>>> Philipp
>>>
>> lcc hasn't implemented them because of time constraints.
>>
>> They are a memory only format. The x86 transforms them on floats on
>> reading them from RAM. The same for ARM.
>>
>> They reduce the size of the data at the expense of precision. For many
>> applications that can be a bonus, it depends.
>>
> 
> I'm somewhat interested in them, since their implementation could be
> cosiderably faster than float/double on machines without hardware
> support for floating-point operations. Typical examples would be most
> 8-bit µCs.

If the 8-bit machine has some 16-bit support, then 24-bit is another 
option, which gives more precision and range (somewhat better than the 
4-figure log tables I used at school actually).

That would be 8-bit sign/exponent and 16-bit mantissa, which can be 
accessed more tidily. There can't be an extra implied bit unless it can 
be done without requiring 17-bit arithmetic.

I understand the official 16-bit format uses a 10-bit mantissa (11 in 
total) so some 16-bit calculations are needed anyway.

-- 
bartc

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web