[PATCH][binutils][0/3] Add float16 directive for assembling 16-bit floating point numbers.

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[PATCH][binutils][0/3] Add float16 directive for assembling 16-bit floating point numbers.

Barnaby Wilks
Hello,

This is a patch series to implement support for a float16 directive for assembling constant 16 bit floating
point values in either IEEE 754 format or the Arm alternative format (depending on target and configuration).

Barney Wilks (3)

[PATCH][binutils][1/3] Generic support for IEEE 754 floating point numbers.
[PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.
[PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE format) for AArch64 backend.

Reply | Threaded
Open this post in threaded view
|

[PATCH][binutils][1/3] Generic support for IEEE 754 floating point numbers.

Barnaby Wilks
Hello,

This is part of a patch series that implements a directive for
assembling 16-bit floating point constants for Arm and AArch64.

This patch contains generic support for half-precision IEEE 754 floating
point numbers that applies for any
target.

Half precision floating point numbers will be encoded using the IEEE 754
half precision floating point
format - 16 bits in total, 1 for sign, 5 for exponent and 10 bits of
mantissa.

Cross compiled and regtested on aarch64-none-elf,
aarch64-none-linux-gnu, arm-none-eabi and arm-none-linux-gnueabihf.

I don't have write access, so if it's OK then could someone commit on my
behalf?

Thanks,
Barney

gas/ChangeLog:

2019-07-11 Barnaby Wilks <[hidden email]>

* config/atof-ieee.c (H_PRECISION): Macro for precision of float16 type.
(atof_ieee): Set precision and exponent bits for encoding float16 types.
(gen_to_words): NaN and Infinity encoding for float16.
(ieee_md_atof): Set precision for encoding float16 type.



float16_ieee_generic.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Barnaby Wilks
In reply to this post by Barnaby Wilks
Hello,

This is part of a patch series that implements a directive for assembling 16-bit floating point constants for Arm and AArch64.

This patch implements the float16 directive for both the IEEE 754 format and the Arm alternative format for the
Arm backend.

The syntax of the directive is:
.float16 <0-n decimal numbers>
e.g.
.float16 12.0
.float16 0.23, 433.1, 0.06

The Arm alternative format is almost identical to the IEEE 754 format, except that it doesn't
encode for NaNs or Infinity (instead an exponent of 0x1F represents a normalized number in the range
65536 to 131008).

The alternative format is documented in the reference manual:
https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439

Which format is used is controlled by the
.eabi_attribute Tag_ABI_FP_16bit_format, <...>
directive, where if
<...> = 1 then use the IEEE 754 half-precision format else if
<...> = 2 then use the Arm alternative format

Added testcases to verify the correct encoding for both formats (for both big and little endian targets),
as well as tests verifying that warnings are thrown if trying to encode NaN or Infinity when using
the Arm alternative format.
The encodings have been cross referenced with GCC's encoding for __fp16 types to ensure consistency.

Cross compiled and regtested on arm-none-eabi and arm-none-linux-gnueabihf

I don't have write access, so if it's OK then could someone commit on my behalf?

Thanks,
Barney

gas/ChangeLog:

2019-07-11  Barnaby Wilks<[hidden email]>

        * config/tc-arm.c (md_atof): Set precision for float16 type.
        (enum fp_16bit_format): Add enum to represent the 2 float16 encodings.
        (arm_is_largest_exponent_ok): Check for whether to encode with the IEEE or alternative
        format.
        * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that expands to
        arm_is_largest_exponent_ok.
        (arm_is_largest_exponent_ok): Add prototype for arm_is_largest_exponent_ok function.
        * testsuite/gas/arm/float16-bad.d: New test.
        * testsuite/gas/arm/float16-bad.l: New test.
        * testsuite/gas/arm/float16-bad.s: New test.
        * testsuite/gas/arm/float16-be.d: New test.
        * testsuite/gas/arm/float16-be.s: New test.
        * testsuite/gas/arm/float16-le.d: New test.
        * testsuite/gas/arm/float16-le.s: New test.


float16_arm.txt (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE format) for AArch64 backend.

Barnaby Wilks
In reply to this post by Barnaby Wilks
Hello,

This is part of a patch series that implements a directive for assembling 16-bit floating point constants for Arm and AArch64.

This patch implements a float16 directive for assembling 16 bit IEEE 754 floating point numbers
for AArch64.

The syntax of the directive is:
.float16 <0-n decimal numbers>
e.g.
.float16 0.5
.float16 10.2, NaN, 452.09

The floats will always be encoded using the binary16 format as described in the
IEEE 754-2008 standard. There is no need to support Arm's alternative half-precision
format since AArch64 only supports the IEEE format.

Added testcases to verify the correct encoding (for big and little endian targets) and cross-referenced the encodings with
GCC's __fp16 type to ensure consistency.

Cross compiled and regtested on aarch64-none-elf and aarch64-none-linux-gnu with no issues.

I don't have write access, so if it's OK then could someone commit on my behalf?

Thanks,
Barney

gas/ChangeLog:

2019-07-11  Barnaby Wilks<[hidden email]>

        * config/tc-aarch64.c: Add float16 directive and add "Hh" to acceptable float
        characters.
        * testsuite/gas/aarch64/float16-be.d: New test.
        * testsuite/gas/aarch64/float16-be.s: New test.
        * testsuite/gas/aarch64/float16-le.d: New test.
        * testsuite/gas/aarch64/float16-le.s: New test.


float16_aarch64.txt (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Richard Earnshaw (lists)
In reply to this post by Barnaby Wilks


On 11/07/2019 16:26, Barnaby Wilks wrote:

> Hello,
>
> This is part of a patch series that implements a directive for assembling 16-bit floating point constants for Arm and AArch64.
>
> This patch implements the float16 directive for both the IEEE 754 format and the Arm alternative format for the
> Arm backend >
> The syntax of the directive is:
> .float16 <0-n decimal numbers>
> e.g.
> .float16 12.0
> .float16 0.23, 433.1, 0.06
>
> The Arm alternative format is almost identical to the IEEE 754 format, except that it doesn't
> encode for NaNs or Infinity (instead an exponent of 0x1F represents a normalized number in the range
> 65536 to 131008).
>
> The alternative format is documented in the reference manual:
> https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439
>
> Which format is used is controlled by the
> .eabi_attribute Tag_ABI_FP_16bit_format, <...>
> directive, where if
> <...> = 1 then use the IEEE 754 half-precision format else if
> <...> = 2 then use the Arm alternative format
>
> Added testcases to verify the correct encoding for both formats (for both big and little endian targets),
> as well as tests verifying that warnings are thrown if trying to encode NaN or Infinity when using
> the Arm alternative format.
> The encodings have been cross referenced with GCC's encoding for __fp16 types to ensure consistency.
>
> Cross compiled and regtested on arm-none-eabi and arm-none-linux-gnueabihf
>
> I don't have write access, so if it's OK then could someone commit on my behalf?
>

Hi Barney,

thanks for the patch.

I'm not sure that using the build attributes to control selection of the
format is the best idea.  Firstly, build attributes are not available
when not assembling for ELF (we have PE-coff support in the assembler as
well); secondly, build attributes should reflect what was placed in the
assembly file, not control what goes into it.  So this is a case of the
coach before the horse.

I think, if we want to support the Arm alternate FP format in GAS at
all, we need either a new command line option, or a new directive (or
possibly both).  Then the code in BFD that does automatic
build-attribute selection should be updated to reflect the tri-state
situation: no format specified; IEEE format specified; or ARM Alternate
format specified.

Note that GAS can currently only reflect show build attributes that
affect the whole file, so switching during assembly is a little dubious
as things stand.


R.


> Thanks,
> Barney
>
> gas/ChangeLog:
>
> 2019-07-11  Barnaby Wilks<[hidden email]>
>
> * config/tc-arm.c (md_atof): Set precision for float16 type.
> (enum fp_16bit_format): Add enum to represent the 2 float16 encodings.
> (arm_is_largest_exponent_ok): Check for whether to encode with the IEEE or alternative
> format.
> * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that expands to
> arm_is_largest_exponent_ok.
> (arm_is_largest_exponent_ok): Add prototype for arm_is_largest_exponent_ok function.
> * testsuite/gas/arm/float16-bad.d: New test.
> * testsuite/gas/arm/float16-bad.l: New test.
> * testsuite/gas/arm/float16-bad.s: New test.
> * testsuite/gas/arm/float16-be.d: New test.
> * testsuite/gas/arm/float16-be.s: New test.
> * testsuite/gas/arm/float16-le.d: New test.
> * testsuite/gas/arm/float16-le.s: New test.
>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Barnaby Wilks
Hi Richard,

Yep agreed, a dedicated directive would make more sense really - originally I did have something
along those lines (.ieee_fp16_format/.alternative_fp16_format directives for switching between formats), but then
changed upon finding a EABI attribute for the same thing, and seeing that was how GCC did it.
Like you say though, for files that contain a mix of float16's in both IEEE and Alternative formats what would be the
EABI attribute for that be?

This could be solved by just restricting to one format (in which
case a command line option may make more sense), or by inventing
a new EABI attribute? (I'm don't really know much about that, so have no idea if it's feasible).

Regards,

Barney

On 7/15/19 10:16 AM, Richard Earnshaw (lists) wrote:

>
>
> On 11/07/2019 16:26, Barnaby Wilks wrote:
>> Hello,
>>
>> This is part of a patch series that implements a directive for
>> assembling 16-bit floating point constants for Arm and AArch64.
>>
>> This patch implements the float16 directive for both the IEEE 754
>> format and the Arm alternative format for the
>> Arm backend >
>> The syntax of the directive is:
>> .float16 <0-n decimal numbers>
>> e.g.
>> .float16 12.0
>> .float16 0.23, 433.1, 0.06
>>
>> The Arm alternative format is almost identical to the IEEE 754
>> format, except that it doesn't
>> encode for NaNs or Infinity (instead an exponent of 0x1F represents a
>> normalized number in the range
>> 65536 to 131008).
>>
>> The alternative format is documented in the reference manual:
>> https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439 
>>
>>
>> Which format is used is controlled by the
>> .eabi_attribute Tag_ABI_FP_16bit_format, <...>
>> directive, where if
>> <...> = 1 then use the IEEE 754 half-precision format else if
>> <...> = 2 then use the Arm alternative format
>>
>> Added testcases to verify the correct encoding for both formats (for
>> both big and little endian targets),
>> as well as tests verifying that warnings are thrown if trying to
>> encode NaN or Infinity when using
>> the Arm alternative format.
>> The encodings have been cross referenced with GCC's encoding for
>> __fp16 types to ensure consistency.
>>
>> Cross compiled and regtested on arm-none-eabi and
>> arm-none-linux-gnueabihf
>>
>> I don't have write access, so if it's OK then could someone commit on
>> my behalf?
>>
>
> Hi Barney,
>
> thanks for the patch.
>
> I'm not sure that using the build attributes to control selection of
> the format is the best idea.  Firstly, build attributes are not
> available when not assembling for ELF (we have PE-coff support in the
> assembler as well); secondly, build attributes should reflect what was
> placed in the assembly file, not control what goes into it.  So this
> is a case of the coach before the horse.
>
> I think, if we want to support the Arm alternate FP format in GAS at
> all, we need either a new command line option, or a new directive (or
> possibly both).  Then the code in BFD that does automatic
> build-attribute selection should be updated to reflect the tri-state
> situation: no format specified; IEEE format specified; or ARM
> Alternate format specified.
>
> Note that GAS can currently only reflect show build attributes that
> affect the whole file, so switching during assembly is a little
> dubious as things stand.
>
>
> R.
>
>
>> Thanks,
>> Barney
>>
>> gas/ChangeLog:
>>
>> 2019-07-11  Barnaby Wilks<[hidden email]>
>>
>>     * config/tc-arm.c (md_atof): Set precision for float16 type.
>>     (enum fp_16bit_format): Add enum to represent the 2 float16
>> encodings.
>>     (arm_is_largest_exponent_ok): Check for whether to encode with
>> the IEEE or alternative
>>     format.
>>     * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that
>> expands to
>>     arm_is_largest_exponent_ok.
>>     (arm_is_largest_exponent_ok): Add prototype for
>> arm_is_largest_exponent_ok function.
>>     * testsuite/gas/arm/float16-bad.d: New test.
>>     * testsuite/gas/arm/float16-bad.l: New test.
>>     * testsuite/gas/arm/float16-bad.s: New test.
>>     * testsuite/gas/arm/float16-be.d: New test.
>>     * testsuite/gas/arm/float16-be.s: New test.
>>     * testsuite/gas/arm/float16-le.d: New test.
>>     * testsuite/gas/arm/float16-le.s: New test.
>>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Richard Earnshaw (lists)


On 15/07/2019 16:44, Barnaby Wilks wrote:

> Hi Richard,
>
> Yep agreed, a dedicated directive would make more sense really - originally I did have something
> along those lines (.ieee_fp16_format/.alternative_fp16_format directives for switching between formats), but then
> changed upon finding a EABI attribute for the same thing, and seeing that was how GCC did it.
> Like you say though, for files that contain a mix of float16's in both IEEE and Alternative formats what would be the
> EABI attribute for that be?
>
> This could be solved by just restricting to one format (in which
> case a command line option may make more sense), or by inventing
> a new EABI attribute? (I'm don't really know much about that, so have no idea if it's feasible).
>

GCC already has the command-line option
-mfp16-format=(none|ieee|alternative).  I'd suggest we have the same,
and have an assembly attribute directive with a similar style.

For the directive, however, the default can be a little more lax: I
think the assembler should start in a mode where the format is
'tentatively ieee' format.  Then, if a .float16 appears with no format
override, we'd make that an explicit format selection.  At the end of
assembly, when then generating build attributes (if doing that
automatically, we'd update the build attributes if the format is at that
point explicit.

The tentative nature is important to avoid changing behaviour for
existing files: we don't want them to start writing out additional build
attributes that they did not generate previously, however, ieee format
is far more common than than alternative format, so requiring users to
always specify this before ever using .float16 would be a little awkward.

R.

> Regards,
>
> Barney
>
> On 7/15/19 10:16 AM, Richard Earnshaw (lists) wrote:
>>
>>
>> On 11/07/2019 16:26, Barnaby Wilks wrote:
>>> Hello,
>>>
>>> This is part of a patch series that implements a directive for
>>> assembling 16-bit floating point constants for Arm and AArch64.
>>>
>>> This patch implements the float16 directive for both the IEEE 754
>>> format and the Arm alternative format for the
>>> Arm backend >
>>> The syntax of the directive is:
>>> .float16 <0-n decimal numbers>
>>> e.g.
>>> .float16 12.0
>>> .float16 0.23, 433.1, 0.06
>>>
>>> The Arm alternative format is almost identical to the IEEE 754
>>> format, except that it doesn't
>>> encode for NaNs or Infinity (instead an exponent of 0x1F represents a
>>> normalized number in the range
>>> 65536 to 131008).
>>>
>>> The alternative format is documented in the reference manual:
>>> https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439
>>>
>>>
>>> Which format is used is controlled by the
>>> .eabi_attribute Tag_ABI_FP_16bit_format, <...>
>>> directive, where if
>>> <...> = 1 then use the IEEE 754 half-precision format else if
>>> <...> = 2 then use the Arm alternative format
>>>
>>> Added testcases to verify the correct encoding for both formats (for
>>> both big and little endian targets),
>>> as well as tests verifying that warnings are thrown if trying to
>>> encode NaN or Infinity when using
>>> the Arm alternative format.
>>> The encodings have been cross referenced with GCC's encoding for
>>> __fp16 types to ensure consistency.
>>>
>>> Cross compiled and regtested on arm-none-eabi and
>>> arm-none-linux-gnueabihf
>>>
>>> I don't have write access, so if it's OK then could someone commit on
>>> my behalf?
>>>
>>
>> Hi Barney,
>>
>> thanks for the patch.
>>
>> I'm not sure that using the build attributes to control selection of
>> the format is the best idea.  Firstly, build attributes are not
>> available when not assembling for ELF (we have PE-coff support in the
>> assembler as well); secondly, build attributes should reflect what was
>> placed in the assembly file, not control what goes into it.  So this
>> is a case of the coach before the horse.
>>
>> I think, if we want to support the Arm alternate FP format in GAS at
>> all, we need either a new command line option, or a new directive (or
>> possibly both).  Then the code in BFD that does automatic
>> build-attribute selection should be updated to reflect the tri-state
>> situation: no format specified; IEEE format specified; or ARM
>> Alternate format specified.
>>
>> Note that GAS can currently only reflect show build attributes that
>> affect the whole file, so switching during assembly is a little
>> dubious as things stand.
>>
>>
>> R.
>>
>>
>>> Thanks,
>>> Barney
>>>
>>> gas/ChangeLog:
>>>
>>> 2019-07-11  Barnaby Wilks<[hidden email]>
>>>
>>>      * config/tc-arm.c (md_atof): Set precision for float16 type.
>>>      (enum fp_16bit_format): Add enum to represent the 2 float16
>>> encodings.
>>>      (arm_is_largest_exponent_ok): Check for whether to encode with
>>> the IEEE or alternative
>>>      format.
>>>      * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that
>>> expands to
>>>      arm_is_largest_exponent_ok.
>>>      (arm_is_largest_exponent_ok): Add prototype for
>>> arm_is_largest_exponent_ok function.
>>>      * testsuite/gas/arm/float16-bad.d: New test.
>>>      * testsuite/gas/arm/float16-bad.l: New test.
>>>      * testsuite/gas/arm/float16-bad.s: New test.
>>>      * testsuite/gas/arm/float16-be.d: New test.
>>>      * testsuite/gas/arm/float16-be.s: New test.
>>>      * testsuite/gas/arm/float16-le.d: New test.
>>>      * testsuite/gas/arm/float16-le.s: New test.
>>>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Tamar Christina-2

Introducing a new directive for this seems counter intuitive to me. Particularly you open up some room for user error to happen more easily especially with inline assembly.

You also then have to Orchestrate gcc to emit these as well in order for the file to be logically consistent with the command line options the user specified. If this is a directive gcc has to emit it as well.

Lastly it also duplicates information. Now the user has two directives to set when using fp16 in an arm assembly file and also opens up the weird possibility to have your built attribute be different from the "encoding type" directive which is a bit nonsensical.

Personally I would say If you're really keen on doing this that I'd much rather have either two float16 directives or for the float16 directive to take an optional "format" specifier rather than commandline options which would complicate support in gcc.

The fact that some platforms like PE don't support built attribute aren't an issue, as those platforms already wouldn't be able to switch formats and be stuck at the "default" one. In fact do we even support fp16 on these non-elf platforms.

Regards,
Tamar

________________________________________
From: [hidden email] <[hidden email]> on behalf of Richard Earnshaw (lists) <[hidden email]>
Sent: Monday, July 15, 2019 5:11:25 PM
To: Barnaby Wilks; [hidden email]
Cc: nd; [hidden email]; Ramana Radhakrishnan
Subject: Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.



On 15/07/2019 16:44, Barnaby Wilks wrote:

> Hi Richard,
>
> Yep agreed, a dedicated directive would make more sense really - originally I did have something
> along those lines (.ieee_fp16_format/.alternative_fp16_format directives for switching between formats), but then
> changed upon finding a EABI attribute for the same thing, and seeing that was how GCC did it.
> Like you say though, for files that contain a mix of float16's in both IEEE and Alternative formats what would be the
> EABI attribute for that be?
>
> This could be solved by just restricting to one format (in which
> case a command line option may make more sense), or by inventing
> a new EABI attribute? (I'm don't really know much about that, so have no idea if it's feasible).
>

GCC already has the command-line option
-mfp16-format=(none|ieee|alternative).  I'd suggest we have the same,
and have an assembly attribute directive with a similar style.

For the directive, however, the default can be a little more lax: I
think the assembler should start in a mode where the format is
'tentatively ieee' format.  Then, if a .float16 appears with no format
override, we'd make that an explicit format selection.  At the end of
assembly, when then generating build attributes (if doing that
automatically, we'd update the build attributes if the format is at that
point explicit.

The tentative nature is important to avoid changing behaviour for
existing files: we don't want them to start writing out additional build
attributes that they did not generate previously, however, ieee format
is far more common than than alternative format, so requiring users to
always specify this before ever using .float16 would be a little awkward.

R.

> Regards,
>
> Barney
>
> On 7/15/19 10:16 AM, Richard Earnshaw (lists) wrote:
>>
>>
>> On 11/07/2019 16:26, Barnaby Wilks wrote:
>>> Hello,
>>>
>>> This is part of a patch series that implements a directive for
>>> assembling 16-bit floating point constants for Arm and AArch64.
>>>
>>> This patch implements the float16 directive for both the IEEE 754
>>> format and the Arm alternative format for the
>>> Arm backend >
>>> The syntax of the directive is:
>>> .float16 <0-n decimal numbers>
>>> e.g.
>>> .float16 12.0
>>> .float16 0.23, 433.1, 0.06
>>>
>>> The Arm alternative format is almost identical to the IEEE 754
>>> format, except that it doesn't
>>> encode for NaNs or Infinity (instead an exponent of 0x1F represents a
>>> normalized number in the range
>>> 65536 to 131008).
>>>
>>> The alternative format is documented in the reference manual:
>>> https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439
>>>
>>>
>>> Which format is used is controlled by the
>>> .eabi_attribute Tag_ABI_FP_16bit_format, <...>
>>> directive, where if
>>> <...> = 1 then use the IEEE 754 half-precision format else if
>>> <...> = 2 then use the Arm alternative format
>>>
>>> Added testcases to verify the correct encoding for both formats (for
>>> both big and little endian targets),
>>> as well as tests verifying that warnings are thrown if trying to
>>> encode NaN or Infinity when using
>>> the Arm alternative format.
>>> The encodings have been cross referenced with GCC's encoding for
>>> __fp16 types to ensure consistency.
>>>
>>> Cross compiled and regtested on arm-none-eabi and
>>> arm-none-linux-gnueabihf
>>>
>>> I don't have write access, so if it's OK then could someone commit on
>>> my behalf?
>>>
>>
>> Hi Barney,
>>
>> thanks for the patch.
>>
>> I'm not sure that using the build attributes to control selection of
>> the format is the best idea.  Firstly, build attributes are not
>> available when not assembling for ELF (we have PE-coff support in the
>> assembler as well); secondly, build attributes should reflect what was
>> placed in the assembly file, not control what goes into it.  So this
>> is a case of the coach before the horse.
>>
>> I think, if we want to support the Arm alternate FP format in GAS at
>> all, we need either a new command line option, or a new directive (or
>> possibly both).  Then the code in BFD that does automatic
>> build-attribute selection should be updated to reflect the tri-state
>> situation: no format specified; IEEE format specified; or ARM
>> Alternate format specified.
>>
>> Note that GAS can currently only reflect show build attributes that
>> affect the whole file, so switching during assembly is a little
>> dubious as things stand.
>>
>>
>> R.
>>
>>
>>> Thanks,
>>> Barney
>>>
>>> gas/ChangeLog:
>>>
>>> 2019-07-11  Barnaby Wilks<[hidden email]>
>>>
>>>      * config/tc-arm.c (md_atof): Set precision for float16 type.
>>>      (enum fp_16bit_format): Add enum to represent the 2 float16
>>> encodings.
>>>      (arm_is_largest_exponent_ok): Check for whether to encode with
>>> the IEEE or alternative
>>>      format.
>>>      * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that
>>> expands to
>>>      arm_is_largest_exponent_ok.
>>>      (arm_is_largest_exponent_ok): Add prototype for
>>> arm_is_largest_exponent_ok function.
>>>      * testsuite/gas/arm/float16-bad.d: New test.
>>>      * testsuite/gas/arm/float16-bad.l: New test.
>>>      * testsuite/gas/arm/float16-bad.s: New test.
>>>      * testsuite/gas/arm/float16-be.d: New test.
>>>      * testsuite/gas/arm/float16-be.s: New test.
>>>      * testsuite/gas/arm/float16-le.d: New test.
>>>      * testsuite/gas/arm/float16-le.s: New test.
>>>
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Richard Earnshaw (lists)


On 16/07/2019 02:59, Tamar Christina wrote:
>
> Introducing a new directive for this seems counter intuitive to me. Particularly you open up some room for user error to happen more easily especially with inline assembly.

I expect the main usecase for this to be completely hand-written
assembly.  GCC never outputs any .float type directives but translates
the values it needs directly into the appropriate decimal constants for
the encoded values.

>
> You also then have to Orchestrate gcc to emit these as well in order for the file to be logically consistent with the command line options the user specified. If this is a directive gcc has to emit it as well.

No, see above.

>
> Lastly it also duplicates information. Now the user has two directives to set when using fp16 in an arm assembly file and also opens up the weird possibility to have your built attribute be different from the "encoding type" directive which is a bit nonsensical.

No, it doesn't.  We can get gas to add the relevant build attributes
when generating the output, if needed based on what directives the user
actually put into their code (and whether or not they made use of the
controlling option).  So no more duplication than we have for, say, .cpu
or .arch.

>
> Personally I would say If you're really keen on doing this that I'd much rather have either two float16 directives or for the float16 directive to take an optional "format" specifier rather than commandline options which would complicate support in gcc.
>
> The fact that some platforms like PE don't support built attribute aren't an issue, as those platforms already wouldn't be able to switch formats and be stuck at the "default" one. In fact do we even support fp16 on these non-elf platforms.

It is an issue.  The attributes are stored in elf-specific extensions
for the BFD.  They don't exist in COFF.  Furthermore, coff users simply
don't expect to do this in their assembly code.

Finally, build attributes are pretty non-intuitive in their encoding.
Expecting users to understand the value system is an insane idea.

R.

>
> Regards,
> Tamar
>
> ________________________________________
> From: [hidden email] <[hidden email]> on behalf of Richard Earnshaw (lists) <[hidden email]>
> Sent: Monday, July 15, 2019 5:11:25 PM
> To: Barnaby Wilks; [hidden email]
> Cc: nd; [hidden email]; Ramana Radhakrishnan
> Subject: Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.
>
>
>
> On 15/07/2019 16:44, Barnaby Wilks wrote:
>> Hi Richard,
>>
>> Yep agreed, a dedicated directive would make more sense really - originally I did have something
>> along those lines (.ieee_fp16_format/.alternative_fp16_format directives for switching between formats), but then
>> changed upon finding a EABI attribute for the same thing, and seeing that was how GCC did it.
>> Like you say though, for files that contain a mix of float16's in both IEEE and Alternative formats what would be the
>> EABI attribute for that be?
>>
>> This could be solved by just restricting to one format (in which
>> case a command line option may make more sense), or by inventing
>> a new EABI attribute? (I'm don't really know much about that, so have no idea if it's feasible).
>>
>
> GCC already has the command-line option
> -mfp16-format=(none|ieee|alternative).  I'd suggest we have the same,
> and have an assembly attribute directive with a similar style.
>
> For the directive, however, the default can be a little more lax: I
> think the assembler should start in a mode where the format is
> 'tentatively ieee' format.  Then, if a .float16 appears with no format
> override, we'd make that an explicit format selection.  At the end of
> assembly, when then generating build attributes (if doing that
> automatically, we'd update the build attributes if the format is at that
> point explicit.
>
> The tentative nature is important to avoid changing behaviour for
> existing files: we don't want them to start writing out additional build
> attributes that they did not generate previously, however, ieee format
> is far more common than than alternative format, so requiring users to
> always specify this before ever using .float16 would be a little awkward.
>
> R.
>
>> Regards,
>>
>> Barney
>>
>> On 7/15/19 10:16 AM, Richard Earnshaw (lists) wrote:
>>>
>>>
>>> On 11/07/2019 16:26, Barnaby Wilks wrote:
>>>> Hello,
>>>>
>>>> This is part of a patch series that implements a directive for
>>>> assembling 16-bit floating point constants for Arm and AArch64.
>>>>
>>>> This patch implements the float16 directive for both the IEEE 754
>>>> format and the Arm alternative format for the
>>>> Arm backend >
>>>> The syntax of the directive is:
>>>> .float16 <0-n decimal numbers>
>>>> e.g.
>>>> .float16 12.0
>>>> .float16 0.23, 433.1, 0.06
>>>>
>>>> The Arm alternative format is almost identical to the IEEE 754
>>>> format, except that it doesn't
>>>> encode for NaNs or Infinity (instead an exponent of 0x1F represents a
>>>> normalized number in the range
>>>> 65536 to 131008).
>>>>
>>>> The alternative format is documented in the reference manual:
>>>> https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439
>>>>
>>>>
>>>> Which format is used is controlled by the
>>>> .eabi_attribute Tag_ABI_FP_16bit_format, <...>
>>>> directive, where if
>>>> <...> = 1 then use the IEEE 754 half-precision format else if
>>>> <...> = 2 then use the Arm alternative format
>>>>
>>>> Added testcases to verify the correct encoding for both formats (for
>>>> both big and little endian targets),
>>>> as well as tests verifying that warnings are thrown if trying to
>>>> encode NaN or Infinity when using
>>>> the Arm alternative format.
>>>> The encodings have been cross referenced with GCC's encoding for
>>>> __fp16 types to ensure consistency.
>>>>
>>>> Cross compiled and regtested on arm-none-eabi and
>>>> arm-none-linux-gnueabihf
>>>>
>>>> I don't have write access, so if it's OK then could someone commit on
>>>> my behalf?
>>>>
>>>
>>> Hi Barney,
>>>
>>> thanks for the patch.
>>>
>>> I'm not sure that using the build attributes to control selection of
>>> the format is the best idea.  Firstly, build attributes are not
>>> available when not assembling for ELF (we have PE-coff support in the
>>> assembler as well); secondly, build attributes should reflect what was
>>> placed in the assembly file, not control what goes into it.  So this
>>> is a case of the coach before the horse.
>>>
>>> I think, if we want to support the Arm alternate FP format in GAS at
>>> all, we need either a new command line option, or a new directive (or
>>> possibly both).  Then the code in BFD that does automatic
>>> build-attribute selection should be updated to reflect the tri-state
>>> situation: no format specified; IEEE format specified; or ARM
>>> Alternate format specified.
>>>
>>> Note that GAS can currently only reflect show build attributes that
>>> affect the whole file, so switching during assembly is a little
>>> dubious as things stand.
>>>
>>>
>>> R.
>>>
>>>
>>>> Thanks,
>>>> Barney
>>>>
>>>> gas/ChangeLog:
>>>>
>>>> 2019-07-11  Barnaby Wilks<[hidden email]>
>>>>
>>>>       * config/tc-arm.c (md_atof): Set precision for float16 type.
>>>>       (enum fp_16bit_format): Add enum to represent the 2 float16
>>>> encodings.
>>>>       (arm_is_largest_exponent_ok): Check for whether to encode with
>>>> the IEEE or alternative
>>>>       format.
>>>>       * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that
>>>> expands to
>>>>       arm_is_largest_exponent_ok.
>>>>       (arm_is_largest_exponent_ok): Add prototype for
>>>> arm_is_largest_exponent_ok function.
>>>>       * testsuite/gas/arm/float16-bad.d: New test.
>>>>       * testsuite/gas/arm/float16-bad.l: New test.
>>>>       * testsuite/gas/arm/float16-bad.s: New test.
>>>>       * testsuite/gas/arm/float16-be.d: New test.
>>>>       * testsuite/gas/arm/float16-be.s: New test.
>>>>       * testsuite/gas/arm/float16-le.d: New test.
>>>>       * testsuite/gas/arm/float16-le.s: New test.
>>>>
Reply | Threaded
Open this post in threaded view
|

RE: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE format) for AArch64 backend.

Tamar Christina-2
In reply to this post by Barnaby Wilks
Hi Barnaby,

Thanks for the patch!

Your float16-le.s and float-16-be.s look identical to me. Could you delete one and rename it to float16.s and use that as the source for both.

Also could you add a NEWS entry for both these and the AArch32 patches.

Thanks,
Tamar
 

> -----Original Message-----
> From: [hidden email] <[hidden email]> On
> Behalf Of Barnaby Wilks
> Sent: Thursday, July 11, 2019 16:27
> To: [hidden email]
> Cc: nd <[hidden email]>; Richard Earnshaw <[hidden email]>;
> Marcus Shawcroft <[hidden email]>
> Subject: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE
> format) for AArch64 backend.
>
> Hello,
>
> This is part of a patch series that implements a directive for
> assembling 16-bit floating point constants for Arm and AArch64.
>
> This patch implements a float16 directive for assembling 16 bit IEEE
> 754 floating point numbers for AArch64.
>
> The syntax of the directive is:
> .float16 <0-n decimal numbers>
> e.g.
> .float16 0.5
> .float16 10.2, NaN, 452.09
>
> The floats will always be encoded using the binary16 format as
> described in the IEEE 754-2008 standard. There is no need to support
> Arm's alternative half-precision format since AArch64 only supports the IEEE format.
>
> Added testcases to verify the correct encoding (for big and little
> endian
> targets) and cross-referenced the encodings with GCC's __fp16 type to
> ensure consistency.
>
> Cross compiled and regtested on aarch64-none-elf and
> aarch64-none-linux- gnu with no issues.
>
> I don't have write access, so if it's OK then could someone commit on
> my behalf?
>
> Thanks,
> Barney
>
> gas/ChangeLog:
>
> 2019-07-11  Barnaby Wilks<[hidden email]>
>
> * config/tc-aarch64.c: Add float16 directive and add "Hh" to
> acceptable float
> characters.
> * testsuite/gas/aarch64/float16-be.d: New test.
> * testsuite/gas/aarch64/float16-be.s: New test.
> * testsuite/gas/aarch64/float16-le.d: New test.
> * testsuite/gas/aarch64/float16-le.s: New test.

Reply | Threaded
Open this post in threaded view
|

RE: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE format) for AArch64 backend.

Tamar Christina-2
And also document the new directive in gas/doc/c-aarch64.texi (and same for the Arm equivalent).

Thanks,
Tamar

> -----Original Message-----
> From: [hidden email] <[hidden email]>
> On Behalf Of Tamar Christina
> Sent: Wednesday, July 24, 2019 12:12
> To: Barnaby Wilks <[hidden email]>; [hidden email]
> Cc: nd <[hidden email]>; Richard Earnshaw <[hidden email]>;
> Marcus Shawcroft <[hidden email]>
> Subject: RE: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE
> format) for AArch64 backend.
>
> Hi Barnaby,
>
> Thanks for the patch!
>
> Your float16-le.s and float-16-be.s look identical to me. Could you delete one
> and rename it to float16.s and use that as the source for both.
>
> Also could you add a NEWS entry for both these and the AArch32 patches.
>
> Thanks,
> Tamar
>
>
> > -----Original Message-----
> > From: [hidden email] <[hidden email]>
> On
> > Behalf Of Barnaby Wilks
> > Sent: Thursday, July 11, 2019 16:27
> > To: [hidden email]
> > Cc: nd <[hidden email]>; Richard Earnshaw <[hidden email]>;
> > Marcus Shawcroft <[hidden email]>
> > Subject: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE
> > format) for AArch64 backend.
> >
> > Hello,
> >
> > This is part of a patch series that implements a directive for
> > assembling 16-bit floating point constants for Arm and AArch64.
> >
> > This patch implements a float16 directive for assembling 16 bit IEEE
> > 754 floating point numbers for AArch64.
> >
> > The syntax of the directive is:
> > .float16 <0-n decimal numbers>
> > e.g.
> > .float16 0.5
> > .float16 10.2, NaN, 452.09
> >
> > The floats will always be encoded using the binary16 format as
> > described in the IEEE 754-2008 standard. There is no need to support
> > Arm's alternative half-precision format since AArch64 only supports the
> IEEE format.
> >
> > Added testcases to verify the correct encoding (for big and little
> > endian
> > targets) and cross-referenced the encodings with GCC's __fp16 type to
> > ensure consistency.
> >
> > Cross compiled and regtested on aarch64-none-elf and
> > aarch64-none-linux- gnu with no issues.
> >
> > I don't have write access, so if it's OK then could someone commit on
> > my behalf?
> >
> > Thanks,
> > Barney
> >
> > gas/ChangeLog:
> >
> > 2019-07-11  Barnaby Wilks<[hidden email]>
> >
> > * config/tc-aarch64.c: Add float16 directive and add "Hh" to
> > acceptable float
> > characters.
> > * testsuite/gas/aarch64/float16-be.d: New test.
> > * testsuite/gas/aarch64/float16-be.s: New test.
> > * testsuite/gas/aarch64/float16-le.d: New test.
> > * testsuite/gas/aarch64/float16-le.s: New test.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Barnaby Wilks
In reply to this post by Barnaby Wilks
Hello,

This is a reworked version of the original patch (https://sourceware.org/ml/binutils/2019-07/msg00116.html) - now the format
used to encode the float16's is controlled by the .float16_format directive and a -mfp16-format option instead of being controlled
by the Tag_ABI_FP_16bit_format EABI attribute.

This is part of a patch series that implements a directive for assembling 16-bit floating point constants for Arm and AArch64.

This patch implements the float16 directive for both the IEEE 754 format and the Arm alternative format for the
Arm backend.

The syntax of the directive is:
.float16 <0-n decimal numbers>
e.g.
.float16 12.0
.float16 0.23, 433.1, 0.06

The Arm alternative format is almost identical to the IEEE 754 format, except that it doesn't
encode for NaNs or Infinity (instead an exponent of 0x1F represents a normalized number in the range
65536 to 131008).

The alternative format is documented in the reference manual:
https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf?_ga=2.72318806.49764181.1561632697-999473562.1560847439

Which format is used is controlled by the
.float16_format <format>
directive, where if
<format> = ieee, then use the IEEE 754 half-precision format else if
<format> = alternative, then use the Arm alternative format

Or the format can be set on the command line via the -mfp16-format option that has a similar syntax.
-mfp16-format=<ieee|alternative>. This also fixes the format and it cannot be changed by any directives.

Once the format has been set (either by the command line option or a directive) it cannot be changed,
and any attempts to change it (i.e. with the float16_format directive) will result in a warning and the
line being ignored.

For ELF targets the appropriate EABI attribute will be written out at the end of assembling
if the format has been explicitly specified. If no format has been explicitly specified then no
EABI attributes will be written.

If the format is not explicitly specified then any float16 directives are encoding using the IEEE 754-2008
format by default until the format is fixed or changed with the float16_format directive.

Added testcases to verify the correct encoding for both formats (for both big and little endian targets),
as well as tests verifying that warnings are thrown if trying to encode NaN or Infinity when using
the Arm alternative format. Tests verifying that trying to set different formats is as expected (i.e.
only use the first specified format) and tests to verify that (for ELF targets) EABI attributes are written
(or not written) correctly.
The encodings have been cross referenced with GCC's encoding for __fp16 types to ensure consistency.

Cross compiled and regtested on arm-none-eabi and arm-none-linux-gnueabihf

I don't have write access, so if it's OK then could someone commit on my behalf?

Thanks,
Barney

gas/ChangeLog:

2019-08-29  Barnaby Wilks<[hidden email]>

        * config/tc-arm.c (enum fp_16bit_format): Add enum to represent the 2 float16 encodings.
        (md_atof): Set precision for float16 type.
        (arm_is_largest_exponent_ok): Check for whether to encode with the IEEE or alternative
        format.
        (set_fp16_format): Parse a float16_format directive.
        (arm_parse_fp16_opt): Parse the fp16-format command line option.
        (aeabi_set_public_attributes): For ELF encode the FP16 format EABI attribute.
        * config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that expands to
        arm_is_largest_exponent_ok.
        (arm_is_largest_exponent_ok): Add prototype for arm_is_largest_exponent_ok function.
        * doc/c-arm.texi: Add documentation for .float16, .float16_format and -mfp16-format=
        * testsuite/gas/arm/float16-bad.d: New test.
        * testsuite/gas/arm/float16-bad.l: New test.
        * testsuite/gas/arm/float16-bad.s: New test.
        * testsuite/gas/arm/float16-be.d: New test.
        * testsuite/gas/arm/float16-format-bad.d: New test.
        * testsuite/gas/arm/float16-format-bad.l: New test.
        * testsuite/gas/arm/float16-format-bad.s: New test.
        * testsuite/gas/arm/float16-format-opt-bad.d: New test.
        * testsuite/gas/arm/float16-format-opt-bad.l: New test.
        * testsuite/gas/arm/float16-le.d: New test.
        * testsuite/gas/arm/float16.s: New test.
        * testsuite/gas/arm/float16-eabi-alternative-format.d: New test.
        * testsuite/gas/arm/float16-eabi-ieee-format.d: New test.
        * testsuite/gas/arm/float16-eabi-no-format.d: New test.
        * testsuite/gas/arm/float16-eabi.s: New test.


float16-arm-updated.txt (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE format) for AArch64 backend.

Barnaby Wilks
In reply to this post by Barnaby Wilks
Hello,

This is an updated patch to include documentation and a NEWS entry for this patch series. (The original patch
is here https://sourceware.org/ml/binutils/2019-07/msg00117.html).

This is part of a patch series that implements a directive for assembling 16-bit floating point constants for Arm and AArch64.
This patch includes a NEWS entry that covers the changes made in this AArch64 patch and the previous Arm patch.

This patch implements a float16 directive for assembling 16 bit IEEE 754 floating point numbers
for AArch64.

The syntax of the directive is:
.float16 <0-n decimal numbers>
e.g.
.float16 0.5
.float16 10.2, NaN, 452.09

The floats will always be encoded using the binary16 format as described in the
IEEE 754-2008 standard. There is no need to support Arm's alternative half-precision
format since AArch64 only supports the IEEE format.

Added testcases to verify the correct encoding (for big and little endian targets) and cross-referenced the encodings with
GCC's __fp16 type to ensure consistency.

Cross compiled and regtested on aarch64-none-elf and aarch64-none-linux-gnu with no issues.

I don't have write access, so if it's OK then could someone commit on my behalf?

Thanks,
Barney

gas/ChangeLog:

2019-08-01  Barnaby Wilks  <[hidden email]>

        * config/tc-aarch64.c: Add float16 directive and add "Hh" to acceptable float
        characters.
        * doc/c-aarch64.texi: Documentation for float16 directive.
        * testsuite/gas/aarch64/float16-be.d: New test.
        * testsuite/gas/aarch64/float16-le.d: New test.
        * testsuite/gas/aarch64/float16.s: New test.
        * NEWS: Add NEWS entry.


float16-updated-aarch64.txt (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Nick Clifton
In reply to this post by Barnaby Wilks
Hi Barnaby,

> Cross compiled and regtested on arm-none-eabi and arm-none-linux-gnueabihf

Are you sure ?  I am seeing the following new assembler failures when I test the patch:

  FAIL: Invalid float16 literals (IEEE 754 & Alternative)
  FAIL: Big endian float16 literals (IEEE 754 & Alternative)
  FAIL: Tag_ABI_FP_16bit_format EABI attribute written for Arm alternative format.
  FAIL: Tag_ABI_FP_16bit_format written for IEEE float16 format.
  FAIL: Tag_ABI_FP_16bit_format EABI attribute not written when format not specified
  FAIL: Invalid combination of command line arguments and directives
  FAIL: Little endian float16 literals (IEEE 754 & Alternative)

(This is with lots of different configurations of ARM based toolchains).

The problem seems to be the same with all of the tests.  Eg:

  gas/testsuite/gas/arm/float16.s: Assembler messages:
  gas/testsuite/gas/arm/float16.s:2: Error: cannot create floating-point number
  gas/testsuite/gas/arm/float16.s:2: Error: junk at end of line, first unrecognized character is `1'

It looks like the patch is maybe missing a change to atof_ieee.c to handle the 'h'
format maybe ?

Cheers
  Nick
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Barnaby Wilks
Hi Nick,

On 8/9/19 1:31 PM, Nick Clifton wrote:

> Hi Barnaby,
>
>> Cross compiled and regtested on arm-none-eabi and arm-none-linux-gnueabihf
> Are you sure ?  I am seeing the following new assembler failures when I test the patch:
>
>    FAIL: Invalid float16 literals (IEEE 754 & Alternative)
>    FAIL: Big endian float16 literals (IEEE 754 & Alternative)
>    FAIL: Tag_ABI_FP_16bit_format EABI attribute written for Arm alternative format.
>    FAIL: Tag_ABI_FP_16bit_format written for IEEE float16 format.
>    FAIL: Tag_ABI_FP_16bit_format EABI attribute not written when format not specified
>    FAIL: Invalid combination of command line arguments and directives
>    FAIL: Little endian float16 literals (IEEE 754 & Alternative)
>
> (This is with lots of different configurations of ARM based toolchains).
>
> The problem seems to be the same with all of the tests.  Eg:
>
>    gas/testsuite/gas/arm/float16.s: Assembler messages:
>    gas/testsuite/gas/arm/float16.s:2: Error: cannot create floating-point number
>    gas/testsuite/gas/arm/float16.s:2: Error: junk at end of line, first unrecognized character is `1'
>
> It looks like the patch is maybe missing a change to atof_ieee.c to handle the 'h'
> format maybe ?

Ah yeah, both the Arm and AArch64 patches require the changes to atof_ieee.c in
        [PATCH][binutils][1/3] Generic support for IEEE 754 floating point numbers.
        ( https://sourceware.org/ml/binutils/2019-07/msg00115.html )

The generic patch add support for the 'h' format, which is (as you say) needed for this patch to work,
otherwise it will rather unhelpfully error.

Apologies for forgetting to mention this, it would have been a useful thing to point out :)

>
> Cheers
>    Nick

Regards,

Barney

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Nick Clifton
Hi Barnaby,

> The generic patch add support for the 'h' format, which is (as you say) needed for this patch to work,
> otherwise it will rather unhelpfully error.
>
> Apologies for forgetting to mention this, it would have been a useful thing to point out :)

Ah - that explains it.  In which case both patches are now approved and applied. :-)

Cheers
  Nick


Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.

Alan Modra-3
arm-nto  +FAIL: Little endian float16 literals (IEEE 754 & Alternative)
arm-pe  +FAIL: Little endian float16 literals (IEEE 754 & Alternative)
arm-wince-pe  +FAIL: Little endian float16 literals (IEEE 754 & Alternative)

--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

[PATCH][binutils][Arm] Float16: Fix test failures for non ELF targets.

Barnaby Wilks
Hello,

This patch fixes test failures for non ELF targets caused by
https://sourceware.org/ml/binutils/2019-08/msg00080.html.

The tests were failing due to md_atof trying to do word-wise endian
switching on the float16 (for little-endian targets sometimes
multi word values have their word order changed).
However since a float16 is only 1 word wide, it would end up writing
incorrect data, as you cannot switch the word order of just one word.

Fixed this by introducing a check (for little-endian targets) for if the
float has a precision of 1 (aka 1 word or 2 bytes in size) then just
emit the value in normal little-endian order and don't try to do the
word wise switching that applies for multi word values.

Cross compiled and regtested on arm-none-eabi, arm-none-linux-gnueabihf,
arm-wince-pe, arm-pe and arm-nto.

Regards,
Barney

gas/ChangeLog:

2019-08-15  Barnaby Wilks  <[hidden email]>

        * config/tc-arm.c (md_atof): Add precision check.




arm-float16-regressions-fix.txt (758 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][Arm] Float16: Fix test failures for non ELF targets.

Alan Modra-3
On Thu, Aug 15, 2019 at 04:21:59PM +0000, Barnaby Wilks wrote:

> diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
> index 840aff2115642eef07356cfc6e811afee78e2134..729e4830912b70245c3ee994ffcd648a0e793f25 100644
> --- a/gas/config/tc-arm.c
> +++ b/gas/config/tc-arm.c
> @@ -1247,7 +1247,7 @@ md_atof (int type, char * litP, int * sizeP)
>      }
>    else
>      {
> -      if (ARM_CPU_HAS_FEATURE (cpu_variant, fpu_endian_pure))
> +      if (ARM_CPU_HAS_FEATURE (cpu_variant, fpu_endian_pure) || prec == 1)
>   for (i = prec - 1; i >= 0; i--)
>    {
>      md_number_to_chars (litP, (valueT) words[i], sizeof (LITTLENUM_TYPE));

Thanks, I applied a slightly different version, putting the prec == 1
test earlier and making the style consistent regarding use of braces
inside an "if".

diff --git a/gas/ChangeLog b/gas/ChangeLog
index 3ac707ce62..51c6c87e40 100644
--- a/gas/ChangeLog
+++ b/gas/ChangeLog
@@ -1,3 +1,7 @@
+2019-08-19  Barnaby Wilks  <[hidden email]>
+
+ * config/tc-arm.c (md_atof): Add precision check.  Formatting.
+
 2019-08-15  Nick Clifton  <[hidden email]>
 
  * po/sv.po: Updated Swedish translation.
diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
index e2b21ed915..c58748dfaa 100644
--- a/gas/config/tc-arm.c
+++ b/gas/config/tc-arm.c
@@ -1237,34 +1237,29 @@ md_atof (int type, char * litP, int * sizeP)
     input_line_pointer = t;
   *sizeP = prec * sizeof (LITTLENUM_TYPE);
 
-  if (target_big_endian)
-    {
-      for (i = 0; i < prec; i++)
- {
-  md_number_to_chars (litP, (valueT) words[i], sizeof (LITTLENUM_TYPE));
-  litP += sizeof (LITTLENUM_TYPE);
- }
-    }
+  if (target_big_endian || prec == 1)
+    for (i = 0; i < prec; i++)
+      {
+ md_number_to_chars (litP, (valueT) words[i], sizeof (LITTLENUM_TYPE));
+ litP += sizeof (LITTLENUM_TYPE);
+      }
+  else if (ARM_CPU_HAS_FEATURE (cpu_variant, fpu_endian_pure))
+    for (i = prec - 1; i >= 0; i--)
+      {
+ md_number_to_chars (litP, (valueT) words[i], sizeof (LITTLENUM_TYPE));
+ litP += sizeof (LITTLENUM_TYPE);
+      }
   else
-    {
-      if (ARM_CPU_HAS_FEATURE (cpu_variant, fpu_endian_pure))
- for (i = prec - 1; i >= 0; i--)
-  {
-    md_number_to_chars (litP, (valueT) words[i], sizeof (LITTLENUM_TYPE));
-    litP += sizeof (LITTLENUM_TYPE);
-  }
-      else
- /* For a 4 byte float the order of elements in `words' is 1 0.
-   For an 8 byte float the order is 1 0 3 2.  */
- for (i = 0; i < prec; i += 2)
-  {
-    md_number_to_chars (litP, (valueT) words[i + 1],
- sizeof (LITTLENUM_TYPE));
-    md_number_to_chars (litP + sizeof (LITTLENUM_TYPE),
- (valueT) words[i], sizeof (LITTLENUM_TYPE));
-    litP += 2 * sizeof (LITTLENUM_TYPE);
-  }
-    }
+    /* For a 4 byte float the order of elements in `words' is 1 0.
+       For an 8 byte float the order is 1 0 3 2.  */
+    for (i = 0; i < prec; i += 2)
+      {
+ md_number_to_chars (litP, (valueT) words[i + 1],
+    sizeof (LITTLENUM_TYPE));
+ md_number_to_chars (litP + sizeof (LITTLENUM_TYPE),
+    (valueT) words[i], sizeof (LITTLENUM_TYPE));
+ litP += 2 * sizeof (LITTLENUM_TYPE);
+      }
 
   return NULL;
 }


--
Alan Modra
Australia Development Lab, IBM
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH][binutils][AArch64][3/3] Add support for float16 (IEEE format) for AArch64 backend.

Barnaby Wilks
In reply to this post by Barnaby Wilks
Hi,

Pinging this patch, could someone give this the once over and apply it
if it's all OK?

This patch doesn't require the generic IEEE float16 patch
(https://sourceware.org/ml/binutils/2019-07/msg00115.html)
to be applied first, as that has already been committed as part of the
Arm patch (https://sourceware.org/ml/binutils/2019-08/msg00080.html).

Regards,

Barney

On 8/8/19 5:27 PM, Barnaby Wilks wrote:

> Hello,
>
> This is an updated patch to include documentation and a NEWS entry for this patch series. (The original patch
> is here https://sourceware.org/ml/binutils/2019-07/msg00117.html).
>
> This is part of a patch series that implements a directive for assembling 16-bit floating point constants for Arm and AArch64.
> This patch includes a NEWS entry that covers the changes made in this AArch64 patch and the previous Arm patch.
>
> This patch implements a float16 directive for assembling 16 bit IEEE 754 floating point numbers
> for AArch64.
>
> The syntax of the directive is:
> .float16 <0-n decimal numbers>
> e.g.
> .float16 0.5
> .float16 10.2, NaN, 452.09
>
> The floats will always be encoded using the binary16 format as described in the
> IEEE 754-2008 standard. There is no need to support Arm's alternative half-precision
> format since AArch64 only supports the IEEE format.
>
> Added testcases to verify the correct encoding (for big and little endian targets) and cross-referenced the encodings with
> GCC's __fp16 type to ensure consistency.
>
> Cross compiled and regtested on aarch64-none-elf and aarch64-none-linux-gnu with no issues.
>
> I don't have write access, so if it's OK then could someone commit on my behalf?
>
> Thanks,
> Barney
>
> gas/ChangeLog:
>
> 2019-08-01  Barnaby Wilks  <[hidden email]>
>
> * config/tc-aarch64.c: Add float16 directive and add "Hh" to acceptable float
> characters.
> * doc/c-aarch64.texi: Documentation for float16 directive.
> * testsuite/gas/aarch64/float16-be.d: New test.
> * testsuite/gas/aarch64/float16-le.d: New test.
> * testsuite/gas/aarch64/float16.s: New test.
> * NEWS: Add NEWS entry.
>
12