mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: Cortex-M support
Date: Thu, 13 Sep 2018 11:43:27 +0200	[thread overview]
Message-ID: <20180913094326.GS4418@port70.net> (raw)
In-Reply-To: <20180913012410.GD1878@brightrain.aerifal.cx>

* Rich Felker <dalias@libc.org> [2018-09-12 21:24:10 -0400]:
> On Thu, Sep 13, 2018 at 03:06:52AM +0200, Pierluigi Passaro wrote:
> > 2) trying to enable hardfp support, the build fails
> > - fabs try calling vabs.f64 assembly instruction
> > - sqrt try calling vsqrt.f64 assembly instruction
> > As far as I understood, vXXX.f64 instructions are only available
> > with single/double precision FPU, not with half precision.

i think half precision is used incorrectly here: single is 32bit
half is 16bit (arm has half precision instructions so mixing these
can be confusing)

> > I'm wondering if the assembly optimization should be wrapped by
> > something like
> >    #if ... && (__ARM_FP > 7)
> > 
> > I'm still trying to setup a reasonable build/test environment, but I
> > suppose I need some suggestions on how to proceed.
> > Any hints?
> 
> Configurations where float and double are anything other than IEEE
> single and double with IEEE-conforming semantics, or where long double
> does not have IEEE-conforming semantics, are not supported/supportable
> by musl, by intent. I would assume there's some way to configure the
> compiler to offer a separate half-precision hardfloat type on an
> otherwise soft-float EABI target with conforming float/double, but if
> not this is a compiler deficiency that makes it impossible to use at
> this time.
> 
> There were some SH4 models that also had this limitation (only
> single-precision FPU) and since GCC's only profile for them redefines
> double as single, rather than doing hard-single and soft-double, we
> just don't support hardfloat at all on them.
> 
> In principle you could build musl as soft-float (with a softfloat
> toolchain) but use a separate toolchain with half-precision hardfloat
> for your applications. There would be no way to call stdlib interfaces
> that take floating point arguments without a glue layer though. Use of
> setjmp/longjmp might also be problematic (failure to restore float
> regs) but this could possibly be mitigated.

note that a large part of the float code in libc is in the
math library which expects efficient double arithmetics,
i plan to rewrite the most important single precision math
functions using double arithmetics, this gives significant
benefits on all systems except ones with single precision
only hw.

(for soft float systems using int arithmetics is the best,
for single prec only systems using single prec arithmetics
is, there are also many places where musl could be better
size optimized, but musl does not have such implementation
variations for maintainability reasons.)


      reply	other threads:[~2018-09-13  9:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13  0:39 Pierluigi Passaro
2018-09-13  0:41 ` Christopher Friedt
2018-09-13  0:52   ` Rich Felker
2018-09-13  1:06     ` Pierluigi Passaro
2018-09-13  1:24       ` Rich Felker
2018-09-13  9:43         ` Szabolcs Nagy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180913094326.GS4418@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).