Re: Cortex M0 Floating Point Library

On 2018-11-13 12:18, Daniel Engel wrote:
> On Tue, Nov 13, 2018, at 1:19 AM, Emmanuel Blot wrote:
>> Daniel Engel wrote on 12/11/2018 19:03:
>>> 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

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.