On 11/5/19 10:39 PM, Peter Maydell wrote:
On Tue, 5 Nov 2019 at 21:23, Hanson, Seth <shan...@sandia.gov> wrote:
I completely understand your concern. Rest assured, this project is entirely
internal and requires no code contribution, unit testing, etc. from QEMU devs.
We simply want to garner as much documentation as possible to ensure optimal
conversion/compatibility. My team and I have already completed a majority of
our instruction set
mapping into TCG. Lately however, we've encountered issues with
floating point operations.
Yeah, for internal forks you have none of the upstreaming
issues (you're merely more on-your-own for figuring out
bugs :-))
I noticed in the TCG Readme that floating point operations are no longer
officially supported but were previously (per the last paragraph in 4.1).
Git blame will tell you that that claim about floating point
has been in there since the readme was first added to
the project in 2008. It would be more accurate to say
simply that TCG does not natively implement fp operations.
TCG's approach to fp is to just (at the TCG opcode level)
treat fp registers the same way as integer ones -- they're
32 bit or 64 bit binary values. Mostly fp operations are
implemented by having the TCG code call out to a helper
function, the same way you'd implement any moderately
complex operation that's not easy to do with inline TCG ops.
From the helper function, you can call the various emulation
functions provided by our generic fpu emulation layer
('softfloat') whose headers are in include/fpu. The FPU
emulation provides IEEE-compliant implementations of
various basic operations; you have to tell it how your target
handles things that IEEE 754 doesn't nail down (eg whether
you detect tininess before or after rounding, what your NaN
format is, that kind of thing), through
a mix of calling the functions that initialize the 'float_status'
and also adding to the target-specific ifdeffery in
fpu/softfloat-specialize.inc.c. When your target needs things
that aren't IEEE-specified you just have to implement
emulation of those in your per-target code (arm does this
for the 'recpe' reciprocal-estimate instruction, for instance).
IEEE cumulative exception flags (inexact, denormal, etc)
are tracked in the float_status and need to be made visible
to the guest in whatever fp status register it uses to show
those. The default assumption is that IEEE exceptions
don't generate guest CPU exceptions, but you can implement
the latter if you need it -- see ppc for an example of that.
Can you please provide documentation for implementing the latter?
As usual for QEMU internals there are no documentation.
You can look at the headers in include/fpu which have some
comments describing the APIs, and at the existing CPUs
which use them to implement their FPU support.
You can also read the git history (of a particular file/directory), you
will learn a lot about API changes and why the design is this way today.
Also, looking at other similar contributions in the mailing list
archives might give you useful hints. In particular when patches were
not accepted, what was the reasons.
Regards,
Phil.
