[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170321165844.GD17319@brightrain.aerifal.cx>
Date: Tue, 21 Mar 2017 12:58:44 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] aarch64: add single instruction math functions
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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
