This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Barnaby Wilks <Barnaby dot Wilks at arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Cc: nd <nd at arm dot com>, "nickc at redhat dot com" <nickc at redhat dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Mon, 15 Jul 2019 10:16:09 +0100
- Subject: Re: [PATCH][binutils][Arm][2/3] Add support for float16 (IEEE and Alternative formats) for Arm backend.
- References: <firstname.lastname@example.org> <email@example.com>
On 11/07/2019 16:26, Barnaby Wilks wrote:
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>
.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:
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 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
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.
2019-07-11 Barnaby Wilks<firstname.lastname@example.org>
* 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
* config/tc-arm.h (TC_LARGEST_EXPONENT_IS_NORMAL): Macro that expands to
(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.