From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109985 invoked by alias); 28 Aug 2015 06:54:43 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 109972 invoked by uid 89); 28 Aug 2015 06:54:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailfilter05.hatteland.com Received: from mailfilter05.hatteland.com (HELO mailfilter05.hatteland.com) (213.162.250.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 28 Aug 2015 06:54:39 +0000 Received: from mailfilter05.hatteland.com (localhost [127.0.0.1]) by mailfilter05.hatteland.com (Postfix) with ESMTP id 1C192FD44B; Fri, 28 Aug 2015 08:54:34 +0200 (CEST) Received: from mailfilter05.hatteland.com (localhost [127.0.0.1]) by mailfilter05.hatteland.com (Postfix) with ESMTP id 92F82FD45F; Fri, 28 Aug 2015 08:54:31 +0200 (CEST) Received: from JHSVMHUB01.netsentral.no (unknown [172.21.1.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailfilter05.hatteland.com (Postfix) with ESMTPS id 78A0EFD42C; Fri, 28 Aug 2015 08:54:31 +0200 (CEST) Received: from [192.168.0.65] (172.21.20.100) by e2010.hatteland.com (172.21.1.25) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 28 Aug 2015 08:54:32 +0200 Message-ID: <55E005A7.6000002@westcontrol.com> Date: Fri, 28 Aug 2015 06:54:00 -0000 From: David Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Martin Sebor , Kostas Savvidis , Subject: Re: 128-bit integer - nonsensical documentation? References: <1B1111BE-E274-4C80-8189-22B78D77647A@gmail.com> <55DDAD64.3040607@westcontrol.com> <55DDE30A.1080506@gmail.com> <55DEB83C.5010106@westcontrol.com> <55DF2814.3050206@gmail.com> In-Reply-To: <55DF2814.3050206@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-SW-Source: 2015-08/txt/msg00204.txt.bz2 On 27/08/15 17:09, Martin Sebor wrote: >> Is it fair to say that the main use of extended integers is to "fill the >> gaps" if the sequence char, short, int, long, long long has missing >> sizes? Such as if an architecture defines int to be 64-bit and short to >> be 32-bit, then you could have an extended integer type for 16-bit? > > Something like that. The extended integer types were invented by > the committee in hopes of a) easing the transition from 16-bit > to 32-bit to 64-bit implementations and b) making it possible for > implementers targeting new special-purpose hardware to extend the > language in useful and hopefully consistent ways to take advantage > of the new hardware. One idea was to support bi-endian types in > the type system. There was no experience with these types when > they were introduced and I don't have the impression they've been > as widely adopted as had been envisioned. Intel Bi-endian compiler > does provide support for "extended" mixed-endian types in the same > program. > By "bi-endian types", you mean something like "int_be32_t" for a 32-bit integer that is viewed as big-endian, regardless of whether the target is big or little endian? (Alternatively, you could have "big_endian", etc., as type qualifiers.) That would be an extremely useful feature - it would make things like file formats, file systems, network protocols, and other data transfer easier and neater. It can also be very handy in embedded systems at times. I know that the Diab Data embedded compiler suite, now owned by Wind River which is now owned by Intel, has support for specifying endianness - at least in structures. If I remember correctly, it is done with qualifiers rather than with extended integer types. I wonder if such mixed endian support would be better done using name address spaces, rather than extended integer types? (Sorry for changing the topic of the thread slightly - control of endianness is one of the top lines in my wish-list for gcc features.) David