This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
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.