From: "Alex Bennée" <alex.bennee@linaro.org>
To: Laurent Vivier <laurent@vivier.eu>
Cc: qemu-devel@nongnu.org
Subject: Re: [PATCH] softfloat,m68k: disable floatx80_invalid_encoding() for m68k
Date: Mon, 06 Jul 2020 17:58:49 +0100 [thread overview]
Message-ID: <87o8ospol2.fsf@linaro.org> (raw)
In-Reply-To: <20200612140400.2130118-1-laurent@vivier.eu> (Laurent Vivier's message of "Fri, 12 Jun 2020 16:04:00 +0200")
Laurent Vivier <laurent@vivier.eu> writes:
> According to the comment, this definition of invalid encoding is given
> by intel developer's manual, and doesn't comply with 680x0 FPU.
>
> With m68k, the explicit integer bit can be zero in the case of:
> - zeros (exp == 0, mantissa == 0)
> - denormalized numbers (exp == 0, mantissa != 0)
> - unnormalized numbers (exp != 0, exp < 0x7FFF)
> - infinities (exp == 0x7FFF, mantissa == 0)
> - not-a-numbers (exp == 0x7FFF, mantissa != 0)
>
> For infinities and NaNs, the explicit integer bit can be either one or
> zero.
>
> The IEEE 754 standard does not define a zero integer bit. Such a number
> is an unnormalized number. Hardware does not directly support
> denormalized and unnormalized numbers, but implicitly supports them by
> trapping them as unimplemented data types, allowing efficient conversion
> in software.
>
> See "M68000 FAMILY PROGRAMMER’S REFERENCE MANUAL",
> "1.6 FLOATING-POINT DATA TYPES"
>
> We will implement in the m68k TCG emulator the FP_UNIMP exception to
> trap into the kernel to normalize the number. In case of linux-user,
> the number will be normalized by QEMU.
>
> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Apologies for the private reply, was using my fallback tooling while
email was down and that doesn't automatically include the group address.
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
By all means take it via the m68k tree.
> ---
> include/fpu/softfloat.h | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/include/fpu/softfloat.h b/include/fpu/softfloat.h
> index 16ca697a73b7..f6eda4ca8e6c 100644
> --- a/include/fpu/softfloat.h
> +++ b/include/fpu/softfloat.h
> @@ -791,7 +791,31 @@ static inline bool floatx80_unordered_quiet(floatx80 a, floatx80 b,
> *----------------------------------------------------------------------------*/
> static inline bool floatx80_invalid_encoding(floatx80 a)
> {
> +#if defined(TARGET_M68K)
> + /*-------------------------------------------------------------------------
> + | With m68k, the explicit integer bit can be zero in the case of:
> + | - zeros (exp == 0, mantissa == 0)
> + | - denormalized numbers (exp == 0, mantissa != 0)
> + | - unnormalized numbers (exp != 0, exp < 0x7FFF)
> + | - infinities (exp == 0x7FFF, mantissa == 0)
> + | - not-a-numbers (exp == 0x7FFF, mantissa != 0)
> + |
> + | For infinities and NaNs, the explicit integer bit can be either one or
> + | zero.
> + |
> + | The IEEE 754 standard does not define a zero integer bit. Such a number
> + | is an unnormalized number. Hardware does not directly support
> + | denormalized and unnormalized numbers, but implicitly supports them by
> + | trapping them as unimplemented data types, allowing efficient conversion
> + | in software.
> + |
> + | See "M68000 FAMILY PROGRAMMER’S REFERENCE MANUAL",
> + | "1.6 FLOATING-POINT DATA TYPES"
> + *------------------------------------------------------------------------*/
> + return false;
> +#else
> return (a.low & (1ULL << 63)) == 0 && (a.high & 0x7FFF) != 0;
> +#endif
> }
>
> #define floatx80_zero make_floatx80(0x0000, 0x0000000000000000LL)
--
Alex Bennée
next prev parent reply other threads:[~2020-07-06 17:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 14:04 [PATCH] softfloat,m68k: disable floatx80_invalid_encoding() for m68k Laurent Vivier
2020-07-06 12:53 ` Laurent Vivier
2020-07-06 16:58 ` Alex Bennée [this message]
2020-07-06 19:44 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o8ospol2.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=laurent@vivier.eu \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).