Re: [EXTERNAL] Re: Adding New, Unsupported ISA to Qemu

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 11/5/19 10:39 PM, Peter Maydell wrote:
> On Tue, 5 Nov 2019 at 21:23, Hanson, Seth <shanson@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.