qemu-e2k/target-sh4
Aleksandar Markovic af39bc8c49 softfloat: Implement run-time-configurable meaning of signaling NaN bit
This patch modifies SoftFloat library so that it can be configured in
run-time in relation to the meaning of signaling NaN bit, while, at the
same time, strictly preserving its behavior on all existing platforms.

Background:

In floating-point calculations, there is a need for denoting undefined or
unrepresentable values. This is achieved by defining certain floating-point
numerical values to be NaNs (which stands for "not a number"). For additional
reasons, virtually all modern floating-point unit implementations use two
kinds of NaNs: quiet and signaling. The binary representations of these two
kinds of NaNs, as a rule, differ only in one bit (that bit is, traditionally,
the first bit of mantissa).

Up to 2008, standards for floating-point did not specify all details about
binary representation of NaNs. More specifically, the meaning of the bit
that is used for distinguishing between signaling and quiet NaNs was not
strictly prescribed. (IEEE 754-2008 was the first floating-point standard
that defined that meaning clearly, see [1], p. 35) As a result, different
platforms took different approaches, and that presented considerable
challenge for multi-platform emulators like QEMU.

Mips platform represents the most complex case among QEMU-supported
platforms regarding signaling NaN bit. Up to the Release 6 of Mips
architecture, "1" in signaling NaN bit denoted signaling NaN, which is
opposite to IEEE 754-2008 standard. From Release 6 on, Mips architecture
adopted IEEE standard prescription, and "0" denotes signaling NaN. On top of
that, Mips architecture for SIMD (also known as MSA, or vector instructions)
also specifies signaling bit in accordance to IEEE standard. MSA unit can be
implemented with both pre-Release 6 and Release 6 main processor units.

QEMU uses SoftFloat library to implement various floating-point-related
instructions on all platforms. The current QEMU implementation allows for
defining meaning of signaling NaN bit during build time, and is implemented
via preprocessor macro called SNAN_BIT_IS_ONE.

On the other hand, the change in this patch enables SoftFloat library to be
configured in run-time. This configuration is meant to occur during CPU
initialization, at the moment when it is definitely known what desired
behavior for particular CPU (or any additional FPUs) is.

The change is implemented so that it is consistent with existing
implementation of similar cases. This means that structure float_status is
used for passing the information about desired signaling NaN bit on each
invocation of SoftFloat functions. The additional field in float_status is
called snan_bit_is_one, which supersedes macro SNAN_BIT_IS_ONE.

IMPORTANT:

This change is not meant to create any change in emulator behavior or
functionality on any platform. It just provides the means for SoftFloat
library to be used in a more flexible way - in other words, it will just
prepare SoftFloat library for usage related to Mips platform and its
specifics regarding signaling bit meaning, which is done in some of
subsequent patches from this series.

Further break down of changes:

  1) Added field snan_bit_is_one to the structure float_status, and
     correspondent setter function set_snan_bit_is_one().

  2) Constants <float16|float32|float64|floatx80|float128>_default_nan
     (used both internally and externally) converted to functions
     <float16|float32|float64|floatx80|float128>_default_nan(float_status*).
     This is necessary since they are dependent on signaling bit meaning.
     At the same time, for the sake of code cleanup and simplicity, constants
     <floatx80|float128>_default_nan_<low|high> (used only internally within
     SoftFloat library) are removed, as not needed.

  3) Added a float_status* argument to SoftFloat library functions
     XXX_is_quiet_nan(XXX a_), XXX_is_signaling_nan(XXX a_),
     XXX_maybe_silence_nan(XXX a_). This argument must be present in
     order to enable correct invocation of new version of functions
     XXX_default_nan(). (XXX is <float16|float32|float64|floatx80|float128>
     here)

  4) Updated code for all platforms to reflect changes in SoftFloat library.
     This change is twofolds: it includes modifications of SoftFloat library
     functions invocations, and an addition of invocation of function
     set_snan_bit_is_one() during CPU initialization, with arguments that
     are appropriate for each particular platform. It was established that
     all platforms zero their main CPU data structures, so snan_bit_is_one(0)
     in appropriate places is not added, as it is not needed.

[1] "IEEE Standard for Floating-Point Arithmetic",
    IEEE Computer Society, August 29, 2008.

Signed-off-by: Thomas Schwinge <thomas@codesourcery.com>
Signed-off-by: Maciej W. Rozycki <macro@codesourcery.com>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic@imgtec.com>
Tested-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Reviewed-by: Leon Alrae <leon.alrae@imgtec.com>
Tested-by: Leon Alrae <leon.alrae@imgtec.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
[leon.alrae@imgtec.com:
 * cherry-picked 2 chunks from patch #2 to fix compilation warnings]
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
2016-06-24 13:40:37 +01:00
..
cpu-qom.h target-sh4: make cpu-qom.h not target specific 2016-05-19 16:41:34 +02:00
cpu.c softfloat: Implement run-time-configurable meaning of signaling NaN bit 2016-06-24 13:40:37 +01:00
cpu.h cpu: move exec-all.h inclusion out of cpu.h 2016-05-19 16:42:29 +02:00
gdbstub.c qemu-common: push cpu.h inclusion out of qemu-common.h 2016-05-19 16:42:29 +02:00
helper.c cpu: move exec-all.h inclusion out of cpu.h 2016-05-19 16:42:29 +02:00
helper.h
Makefile.objs
monitor.c
op_helper.c cpu: move exec-all.h inclusion out of cpu.h 2016-05-19 16:42:29 +02:00
README.sh4
translate.c exec: [tcg] Track which vCPU is performing translation and execution 2016-06-20 15:30:01 +01:00

qemu target:   sh4
author:        Samuel Tardieu <sam@rfc1149.net>
last modified: Tue Dec  6 07:22:44 CET 2005

The sh4 target is not ready at all yet for integration in qemu. This
file describes the current state of implementation.

Most places requiring attention and/or modification can be detected by
looking for "XXXXX" or "abort()".

The sh4 core is located in target-sh4/*, while the 7750 peripheral
features (IO ports for example) are located in hw/sh7750.[ch]. The
main board description is in hw/shix.c, and the NAND flash in
hw/tc58128.[ch].

All the shortcomings indicated here will eventually be resolved. This
is a work in progress. Features are added in a semi-random order: if a
point is blocking to progress on booting the Linux kernel for the shix
board, it is addressed first; if feedback is necessary and no progress
can be made on blocking points until it is received, a random feature
is worked on.

Goals
-----

The primary model being worked on is the soft MMU target to be able to
emulate the Shix 2.0 board by Alexis Polti, described at
http://perso.enst.fr/~polti/realisations/shix20/

Ultimately, qemu will be coupled with a system C or a verilog
simulator to simulate the whole board functionalities.

A sh4 user-mode has also somewhat started but will be worked on
afterwards. The goal is to automate tests for GNAT (GNU Ada) compiler
that I ported recently to the sh4-linux target.

Registers
---------

16 general purpose registers are available at any time. The first 8
registers are banked and the non-directly visible ones can be accessed
by privileged instructions. In qemu, we define 24 general purpose
registers and the code generation use either [0-7]+[8-15] or
[16-23]+[8-15] depending on the MD and RB flags in the sr
configuration register.

Instructions
------------

Most sh4 instructions have been implemented. The missing ones at this
time are:
  - FPU related instructions
  - LDTLB to load a new MMU entry
  - SLEEP to put the processor in sleep mode

Most instructions could be optimized a lot. This will be worked on
after the current model is fully functional unless debugging
convenience requires that it is done early.

Many instructions did not have a chance to be tested yet. The plan is
to implement unit and regression testing of those in the future.

MMU
---

The MMU is implemented in the sh4 core. MMU management has not been
tested at all yet. In the sh7750, it can be manipulated through memory
mapped registers and this part has not yet been implemented.

Exceptions
----------

Exceptions are implemented as described in the sh4 reference manual
but have not been tested yet. They do not use qemu EXCP_ features
yet.

IRQ
---

IRQ are not implemented yet.

Peripheral features
-------------------

  + Serial ports

Configuration and use of the first serial port (SCI) without
interrupts is supported. Input has not yet been tested.

Configuration of the second serial port (SCIF) is supported. FIFO
handling infrastructure has been started but is not completed yet.

  + GPIO ports

GPIO ports have been implemented. A registration function allows
external modules to register interest in some port changes (see
hw/tc58128.[ch] for an example) and will be called back. Interrupt
generation is not yet supported but some infrastructure is in place
for this purpose. Note that in the current model a peripheral module
cannot directly simulate a H->L->H input port transition and have an
interrupt generated on the low level.

  + TC58128 NAND flash

TC58128 NAND flash is partially implemented through GPIO ports. It
supports reading from flash.

GDB
---

GDB remote target support has been implemented and lightly tested.

Files
-----

File names are hardcoded at this time. The bootloader must be stored in
shix_bios.bin in the current directory. The initial Linux image must
be stored in shix_linux_nand.bin in the current directory in NAND
format. Test files can be obtained from
http://perso.enst.fr/~polti/robot/ as well as the various datasheets I
use.

qemu disk parameter on the command line is unused. You can supply any
existing image and it will be ignored. As the goal is to simulate an
embedded target, it is not clear how this parameter will be handled in
the future.

To build an ELF kernel image from the NAND image, 16 bytes have to be
stripped off the end of every 528 bytes, keeping only 512 of them. The
following Python code snippet does it:

#! /usr/bin/python

def denand (infd, outfd):
    while True:
        d = infd.read (528)
        if not d: return
        outfd.write (d[:512])

if __name__ == '__main__':
    import sys
    denand (open (sys.argv[1], 'rb'),
            open (sys.argv[2], 'wb'))

Style isssues
-------------

There is currently a mix between my style (space before opening
parenthesis) and qemu style. This will be resolved before final
integration is proposed.