This is the mail archive of the
mailing list for the eCos project.
[Bug 1001539] Single precision floating point math library
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: unassigned at bugs dot ecos dot sourceware dot org
- Date: Sun, 09 Jun 2013 18:23:35 +0000
- Subject: [Bug 1001539] Single precision floating point math library
- Auto-submitted: auto-generated
- References: <bug-1001539-777 at http dot bugs dot ecos dot sourceware dot org/>
Please do not reply to this email, use the link below.
--- Comment #35 from Ilija Kocho <firstname.lastname@example.org> ---
(In reply to comment #33)
> Created attachment 2255 [details]
> Inline some portable API functions for IEEE only option (incremental)
> Here is a proposal for optimisation of some functions for both space and
> speed. If CYGSEM_LIBM_COMPAT_IEEE_ONLY compatibility option is selected then
> portable API (wrapper) functions became trivial and can be inlined. Inlining
Correction: it's ieee754-api, not portable-api!
> eliminates one step of indirection, producing faster code. The generated
> code in total, is also shorter. At present following portable APIs are
> inlined: atan2/atan2f and hypot/hypotf. The reason for this selection is
> that they are used by basic complex carg/cargf and cabs/cabsf operations
> Inlining option is user selectable and is disabled by default in order to
> preserve backward compatibility
> Here we come to complex number support. My initial intention was to enable
> only basic operations: argument, abs value, conjugation, real and imaginary
> parts (some of them trivial/builtin). However it turned out that complete
> complex library (taken from Newlib) compiled without warnings - almost
> verbatim. Therefore I decided to submit complete complex library as well.
> Most functions are unaltered - hence original copyright banners are
> preserved. The ones that I have altered are (however trivial) different
> enough to publish them under eCos licence. That includes: carg, cabs, conj,
> creal and cimag - all double and float.
> Arguably the complex support could be subject to a separate bug, but IMO it
> fits here well in context of previous paragraph. It is easy to change the
> topic of this bug accordingly.
> Note: This attachment is incremental to 1656+1657+1658 patch collection. It
> does not contain complex functions body. That will be posted in a patch that
You are receiving this mail because:
You are the assignee for the bug.