mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [PATCH] aarch64: add single instruction math functions
Date: Tue, 21 Mar 2017 12:58:44 -0400	[thread overview]
Message-ID: <20170321165844.GD17319@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAGWvnymReOMyOMeGKyHvCMcJjh6mqP0r54XCQF-e2jZAm7PTXA@mail.gmail.com>

On Tue, Mar 21, 2017 at 12:50:46PM -0400, David Edelsohn wrote:
> On Sun, Mar 19, 2017 at 11:05 AM, Rich Felker <dalias@libc.org> wrote:
> > On Sun, Mar 19, 2017 at 08:55:58AM -0400, David Edelsohn wrote:
> >> I thought that the goal of musl was "Minimal machine-specific code".
> >
> > My interpretation of minimal is two-fold:
> >
> > - minimal amount of arch-specific coding required to bring up a new
> >   arch.
> >
> > - when arch-specific code is present by necessity or for optimization
> >   (speed or size), keeping complexity, maintenance cost, and room for
> >   arch-specific bugs minimal.
> >
> > This is not intended to preclude use of single-instruction primitives
> > (see existing code for x86, etc.) for math functions or even critical
> > things that may be somewhat more complex like memcpy.
> 
> This policy makes maintenance more difficult and bugs more difficult
> to analyze because different ports of musl libc may use less common
> code.

This is a good point and actually a reason why I've considered looking
for a good way to structure "mandatory" arch files vs "optimization"
ones, so that you could opt to build without the latter. In the case
of math, there may even be a few cases left where the C code does not
even work correctly on archs (x86, future m68k) with excess precision,
and it would be nice to be able to check it easily and fix any bugs
that remain.

> Single instruction primitives occur more often in CISC architectures
> by definition, so this preferences CISC.

I don't think this is a meaningful distinction. Any modern arch has
floating point instructions for more than just +-*/. Stuff like trig
is definitely CISCy (and likely useless; on x86 it gives wrong results
and it's slower than doing the trig in C anyway) but you most
certainly want the fpu to have sqrt and rounding instructions because
they're very costly to emulate.

> This policy makes the decision process for architecture-specific
> changes much more arbitrary.

If by "arbitrary" you mean "not fitting a minimally-expressable
absolute rule, but very well justified"...

Rich


  reply	other threads:[~2017-03-21 16:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-19  4:26 Szabolcs Nagy
2017-03-19 12:55 ` David Edelsohn
2017-03-19 14:51   ` Szabolcs Nagy
2017-03-19 15:05   ` Rich Felker
2017-03-21 16:50     ` David Edelsohn
2017-03-21 16:58       ` Rich Felker [this message]
2017-03-21 16:50 ` Rich Felker

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=20170321165844.GD17319@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --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).