From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6662 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Further limits/stdint issues Date: Wed, 3 Dec 2014 00:03:34 -0500 Message-ID: <20141203050334.GF4574@brightrain.aerifal.cx> References: <20141203010204.GA5440@brightrain.aerifal.cx> <1DC760B6-F8AA-438A-9743-0266E27405C3@cognitive-electronics.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1417583040 16620 80.91.229.3 (3 Dec 2014 05:04:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 05:04:00 +0000 (UTC) Cc: musl@lists.openwall.com To: Glenn Weinberg Original-X-From: musl-return-6675-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 03 06:03:53 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xw26R-0001x2-6q for gllmg-musl@m.gmane.org; Wed, 03 Dec 2014 06:03:51 +0100 Original-Received: (qmail 26526 invoked by uid 550); 3 Dec 2014 05:03:49 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26512 invoked from network); 3 Dec 2014 05:03:48 -0000 Content-Disposition: inline In-Reply-To: <1DC760B6-F8AA-438A-9743-0266E27405C3@cognitive-electronics.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6662 Archived-At: On Tue, Dec 02, 2014 at 11:10:58PM -0500, Glenn Weinberg wrote: > > > On Dec 2, 2014, at 8:02 PM, Rich Felker wrote: > > > > The fast16/fast32 types and limits are still in bits/stdint.h despite > > not varying between archs. Removing those would make bits/stdint.h > > tiny/trivial. Aside from PAGE_SIZE, both bits/limits.h and > > bits/stdint.h would essentially have no information except > > "long/pointer size" and maybe we could even eventually eliminate them > > by having a global idea of "wordsize". > > I don't think it's safe to make such assumptions. Our architecture > is native 64-bit, so we define all the fast types as 64-bit. Could you elaborate on your motivations? There's no inherent reason that the fast types should be defined as 64-bit just because the native word size is 64-bit, and there are lots of reasons against it. Lots of people misinterpret the "fast" types as "fast unit for moving data", i.e. in the sense of "given N bytes of data to move, what's the fastest type to move it as?" This is not the meaning the C language assigns to them; in fact this sense is rather meaningless since C does not permit the aliasing that would be needed to move data as any type other than its actual type or a character type. Rather, "fast" is a matter of "given N values, possibly with just N=1, what type should be used to optimize operations on the value(s)?" In this sense, it's almost always best for the fast type to be the same as the least type, unless the least type incurs some heavy penalty (e.g. a machine that can't do 16-bit loads and stores and has to emulate them with byte loads/stores or atomic cas on larger words). As an example, take x86_64, where glibc made their [u]int_fast32_t types 64-bit. Addition and subtraction are the same speed for 32- or 64-bit operations, and perhaps multiplication is too (?), but division is significantly slower for 64-bit, and perhaps more importantly, using 64-bit storage doubles the number of cache lines you use and effectively halves the size of your cache. If you have a good reason that the fast types should be 64-bit on some archs, I'd like to hear it. I'm open to listening to alternative views on this. Rich