Future direction of SoftFloat and its development model

[stsquad]

The QEMU project makes extensive use of SoftFloat to model floating point instructions. The source in QEMU's tree is based on SoftFloat2a due to later incompatibilities in the licensing. It has also seen a number of additions over time including specialisation for the various architectures we emulate. Perhaps the biggest one being augmenting the API to pass *float_status to the various operations. This needed to be done as the CPUs we emulate often have different FPU contexts so the floating point flags shouldn't interfere with each other.

As time has moved on and more recent processor revisions require additional features from later revisions of IEE754 we are faced with a dilemma of how to move forward. We can either keep adding features to our copy of 2a or instead port our code to use 3c and it track its future development. However given our extensive changes this doesn't make sense if our internal copy is going to have to be significantly modified and diverge again from the upstream. So this leads to a couple of questions:

• What are the development goals of SoftFloat?
  • why was it originally written and who are its target users?
• Is SoftFloat in active development?
  • under history it is mentioned UC Berkley funded v3. Is this an ongoing commitment or was there a goal in mind?
  • is the project interested in taking patches from the wider community?
• What is SoftFloat's development model?
  • The homepage just suggests mailing John directly but there is this repository. Is future development now here or is this just a fork for the Berkley team?

[jhauser-ucberkeley]

• What are the development goals of SoftFloat?
  • why was it originally written and who are its target users?

The original version of SoftFloat was created to provide IEEE-compliant floating-point operations to a research processor that had no hardware floating-point. The specific processor at the time was Krste Asanovic's Ph.D. project, T0, which was developed in the 1990s at the International Computer Science Institute (ICSI). (Although it's a separate organization, ICSI has always had close ties to the Computer Science Division at the University of California, Berkeley.) After some cleaning and the addition of documentation, the C source code was released in the hope that it might be useful to others.

Up until now, it has never been a goal of SoftFloat to provide the ability to simulate every aspect of any actual floating-point hardware, past or present. The main goal has always been simply to provide IEEE floating-point where there is none in hardware. SoftFloat also exists to support the companion TestFloat program, which can be used for testing a new floating-point implementation.

From our perspective, SoftFloat has mainly been forward-looking, not backward-looking. Real floating-point implementations often include non-standard or non-required options that software rarely if ever needs, such as the ability to call a trap handler on exceptions or to flush underflows to zero. As a general rule, we haven't supported rarely used features in SoftFloat when we believe they're impractical for future hardware or needn't be encouraged. Note the difference: While one might not want to encourage the 80-bit double-extended-precision format either, it's in SoftFloat because its use was far from rare a decade ago. There are also some unorthodox features in SoftFloat such as the "odd" rounding mode, but those are there usually because we believe the features are useful and we more-or-less encourage their widespread adoption.

• Is SoftFloat in active development?
  • under history it is mentioned UC Berkley funded v3. Is this an
    ongoing commitment or was there a goal in mind?

SoftFloat remains in active development, only very slowly right now. Historically, the only significant contributor to SoftFloat has been myself. Due to other projects and obligations, for this year and the
near future I can afford to spend no more than about 2 or 3 hours on SoftFloat/TestFloat per week, averaged over the year. Some weeks, it's possible for me to spend all that time just responding to a few complex inquiries.

• is the project interested in taking patches from the wider
  community?

Yes, maybe, eventually....

Prof. Asanovic, who oversees the funding for this project, says he's happy to consider opening up SoftFloat to the community. The obstacles for the moment start with the fact that a community project should really attempt to have community input and agreement about such things as what features to have and what the function interfaces should be, and maybe how to subdivide SoftFloat into various "silos" for different classes of users. That all involves some time and effort. Prof. Asanovic is currently looking for somebody to manage SoftFloat as a community project, someone with the requisite skills who can commit more time than I'm personally willing to offer.

In the meantime, you have me. I accept suggestions, but I'm afraid you shouldn't expect fast turnaround, nor can I promise a significant change of focus for SoftFloat from what I described above.

• What is SoftFloat's development model?
  • The homepage just suggests mailing John directly but there is this
    repository. Is future development now here or is this just a fork
    for the Berkley team?

In practice, the repository currently is used by other Berkeley projects, but it's not directly open to outside patches. Things posted at GitHub are read and considered as time permits.

[jhauser-ucberkeley]

The source in QEMU's tree is based on SoftFloat2a due to later incompatibilities in the licensing. It has also seen a number of additions over time including specialisation for the various architectures we emulate. Perhaps the biggest one being augmenting the API to pass *float_status to the various operations. This needed to be done as the CPUs we emulate often have different FPU contexts so the floating point flags shouldn't interfere with each other.

The possibility of passing a context structure into each SoftFloat arithmetic function was considered at one time, but we decided on a different solution for a combination of reasons.

We believe that some uses of SoftFloat want to make many calls to SoftFloat arithmetic functions without any swapping of the context between them, while other uses need to establish a selected context before each arithmetic function call and save any context changes after each call. Certain differences between these scenarios were expected:

• For the first kind of use, without frequent context swapping, we believe there could be many call sites, possibly because every instance of operators +, *, etc., for certain data types would get turned into individual SoftFloat calls. It was expected that such uses might have very low overhead between calls.

• For the second kind of use, needing to perform a context swap on every call, we believe the number of call sites is likely to be more limited, maybe as few as one for each supported operation (add, subtract, multiply, etc.), and maybe even less, if pointers to functions are used. The overhead between calls for this kind of use was expected to be high, irrespective of SoftFloat itself.

Because SoftFloat's context for most floating-point formats is small, consisting only of a rounding mode, the exception flags, and maybe (rarely) the tininess detection mode, it was decided that applications of the second kind could afford to call SoftFloat functions with this sequence:

softfloat_roundingMode = ___;
softfloat_detectTininess = ___;  // maybe
softfloat_exceptionFlags = ___;

... one or more SoftFloat arithmetic functions ...

___ = softfloat_exceptionFlags;

This works fine as long as SoftFloat calls are made from only a single thread. To support calls from multiple threads, Release 3b added the option to define the SoftFloat mode and exception flag variables as "thread local" (using thread_local in C).

[mohamed]

I made a pull request (#13 ) that makes the choice of global state vs. per-function-parameter configurable at compile-time. This is useful in projects where, for example, the use of global variables is not permitted.