summaryrefslogtreecommitdiffstats
path: root/hw
diff options
context:
space:
mode:
authorLaurent Vivier2020-06-12 16:04:00 +0200
committerLaurent Vivier2020-07-06 21:41:52 +0200
commitd159dd058c7dc48a9291fde92eaae52a9f26a4d1 (patch)
treec2ca495056262d03af72f17e7d3ab1be7bd530bd /hw
parenttarget/m68k: consolidate physical translation offset into get_physical_address() (diff)
downloadqemu-d159dd058c7dc48a9291fde92eaae52a9f26a4d1.tar.gz
qemu-d159dd058c7dc48a9291fde92eaae52a9f26a4d1.tar.xz
qemu-d159dd058c7dc48a9291fde92eaae52a9f26a4d1.zip
softfloat,m68k: disable floatx80_invalid_encoding() for m68k
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>
Diffstat (limited to 'hw')
0 files changed, 0 insertions, 0 deletions