On Tue, Nov 6, 2018, at 9:28 PM, Joel Sherrill wrote:
>
> On Tue, Nov 6, 2018, 10:32 PM Daniel Engel <lib...@danielengel.com wrote:
>> Hi,
>>
>> Over the past couple of years, I have hand-assembled a new floating point
>> library for the ARM Cortex M0 architecture. I know the M0 is not generally
>> regarded as a number-crunching machine, but I felt it deserved at least some
>> of the attention that has previously been bestowed on the AVR architecture.
>> As this work has been incidental to my employer's line of business, they
>> have tentatively agreed to assign the copyright and facilitate a release of
>> this library as open source.
>
> This sounds like a nice body of work. Congratukations.
>
> Does paranoia pass?
I haven't run paranoia, as it doesn't claim to be a comprehensive test suite.
Per the allowance of the AEABI, my library only supports round-to-nearest, ties
to even. For the basic operations, I tested the applicable cases of the UCB
and ieeeCC754 , plus estensive random testing with the Berkeley
TestFloat/SoftFloat implementation. All of these tests passed in an STM32F0
target environment.
<http://www.netlib.org/fp/>
<http://www.jhauser.us/arithmetic/TestFloat.html>
For other operations not covered by UCB or ieeeCC754, I developed my own cases
using the C# floating point library for the reference operations. Typically, I
tested 50 - 500 cases per function, covering both general and special case
arguments. All functions have complete, tested support for INF, NAN, +/-0, and
subnormals. On-target testing was typically limited to about 64kb per group of
test cases (the flash memory of the STM32F0).
Additionally, while an assembly language implementation is typically difficult
enough by itself, the logf() and sincosf() functions embody somewhat novel
algorithms (as far as I can tell). For these, I proved correctness with an
equivalent C implementation and exhaustive simulation on a PC. The simulation
compared the result for each argument with an equivalent double precision
calculation using the standard C library where possible, and the ttmath library
otherwise.
<https://www.ttmath.org/>
>> * Add everything into the base libgcc,
>> * Add everything into libm (newlib?) and rely on link order to supersede
>> libgcc,
>
> This will almost certainly break at some point, for someone, and be hard to
> even figure out it happened because the code will work but just be bigger or
> slower.
>
>> * Split the implementation with some magic to ensure that libm functions
>> only link in the presence of the correct libgcc,
>
> I think this is the proper solution. It just puts better implementations in
> the place the infrastructure already supports having a target specific option.
There would be some difficult cases in splitting the library, and I haven't yet
quantified all the costs. One problem point might be tanf(), which relies on a
routine shared with divsf3() to calculate the sin/cos ratio with >24 bits of
precision. Splitting the library would require exposing such internal
routines, which don't naturally conform to any procedure call conventions.
Also, loss of control of linking order would require all short branches in the
libm section to be replaced with long branches. This particularly impacts the
exception handling in almost every function.
>
>> * Establish an independent library specific to the Cortex M0 architecture, or
>
> This is likely to get you the smallest number of users. People have to find
> it and then integrate it on their own. Don't make it hard for folks to find
> and use your work.
Agreed. Plus, I don't have the resources or experience to be a long-term
library maintainer. It's not as if basic math functions require constant
maintenance and updating. The original Cortex M3 library by Nicolas Pitre has
only seen a small handful of changes in past decade.
>
>> * Something else entirely...
>>
>> If there is any interest in incorporating this work into GCC, please
>> advise.
>
> I think so but I am just one voice from the RTEMS community. But I think any
> M0 user would be pleased.
>
> --joel
>>
>> Thanks,
>> Daniel Engel
