From: Laurent Vivier <laurent@vivier.eu>
To: qemu-devel@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Laurent Vivier" <laurent@vivier.eu>,
"Aurelien Jarno" <aurelien@aurel32.net>
Subject: [PULL 3/3] softfloat, m68k: disable floatx80_invalid_encoding() for m68k
Date: Mon, 6 Jul 2020 22:05:59 +0200 [thread overview]
Message-ID: <20200706200559.160209-4-laurent@vivier.eu> (raw)
In-Reply-To: <20200706200559.160209-1-laurent@vivier.eu>
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>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20200612140400.2130118-1-laurent@vivier.eu>
---
include/fpu/softfloat.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/include/fpu/softfloat.h b/include/fpu/softfloat.h
index ff4e2605b16d..f1a19df066b7 100644
--- a/include/fpu/softfloat.h
+++ b/include/fpu/softfloat.h
@@ -794,7 +794,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)
--
2.26.2
next prev parent reply other threads:[~2020-07-06 20:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-06 20:05 [PULL 0/3] M68k next patches Laurent Vivier
2020-07-06 20:05 ` [PULL 1/3] target/m68k: fix physical address translation in m68k_cpu_get_phys_page_debug() Laurent Vivier
2020-07-06 20:05 ` [PULL 2/3] target/m68k: consolidate physical translation offset into get_physical_address() Laurent Vivier
2020-07-06 20:05 ` Laurent Vivier [this message]
2020-07-09 10:29 ` [PULL 0/3] M68k next patches Peter Maydell
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=20200706200559.160209-4-laurent@vivier.eu \
--to=laurent@vivier.eu \
--cc=alex.bennee@linaro.org \
--cc=aurelien@aurel32.net \
--cc=peter.maydell@linaro.org \
--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).