Cortex M0 Floating Point Library

[Emmanuel Blot]

Hi Daniel,

Hi,
Over the past couple of years, I have hand-assembled a new floating point library for the ARM Cortex M0 architecture. Last week I started a thread on the GCC mailing list about contributing this library as open source.
If you have any comments on this direction, please advise.

I think it would be nice if it could integrate smoothly with LLVM/clang
as well.
I'm thinking about the compiler-rt library, which I think partially
covers this topic. It's support for ARMv6m is quite shallow AFAICT.

Thanks,
Emmanuel.

[Brian Inglis]

Over the past couple of years, I have hand-assembled a new floating point
library for the ARM Cortex M0 architecture. Last week I started a thread
on the GCC mailing list about contributing this library as open source.
If you have any comments on this direction, please advise.

I think it would be nice if it could integrate smoothly with LLVM/clang as
well. I'm thinking about the compiler-rt library, which I think partially
covers this topic. It's support for ARMv6m is quite shallow AFAICT.

I would be open to that. I'm much more familiar with the "Arm Embedded
Toolchain", but it looks as if compiler-rt tries to follow the libgcc
specification. Internally there are some significant style differences in
the> function preambles and local label definitions. I'm not sure how
particular each project is to this kind of style.> At a glance, the generic "arm" assembly functions in compiler-rt should apply
to cortex M0. However, taking addsf3 as an example, it appears to occupy
~300 bytes as opposed to the ~120 bytes of my library. I did not see
assembly versions of mulsf3/aeabi_fmul or divsf3/aeabi_fdiv. (My library
also has a fixed overhead of ~150 bytes, shared by all floating point
functions.)> I have not posted code yet because I have not discussed copyright assignment
options with the FSF. However, it seems that dual-licensing is fairly common
with this sort of thing.

You may want to discuss copyright assignment and licensing on newlib and
LLVM/clang lists first, as they are permissively BSD/MIT/NCSA/UIUC licensed
allowing them to be combined with vendor sourced code, while remaining
compatible with the GPL, whereas FSF copyrighted works are [L]GPL licensed,
possibly excluding them from use with non-GPL projects like newlib and
clang/llvm, except possibly as link libraries. IANAL