From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11178 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] aarch64: add single instruction math functions Date: Tue, 21 Mar 2017 12:58:44 -0400 Message-ID: <20170321165844.GD17319@brightrain.aerifal.cx> References: <20170319042644.GP2082@port70.net> <20170319150522.GT1693@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1490115541 12686 195.159.176.226 (21 Mar 2017 16:59:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 21 Mar 2017 16:59:01 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11193-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 21 17:58:58 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cqN7X-0002iO-Jb for gllmg-musl@m.gmane.org; Tue, 21 Mar 2017 17:58:55 +0100 Original-Received: (qmail 18126 invoked by uid 550); 21 Mar 2017 16:58:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 18105 invoked from network); 21 Mar 2017 16:58:58 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11178 Archived-At: On Tue, Mar 21, 2017 at 12:50:46PM -0400, David Edelsohn wrote: > On Sun, Mar 19, 2017 at 11:05 AM, Rich Felker 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