From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100533 invoked by alias); 28 Aug 2015 15:30:12 -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 100521 invoked by uid 89); 28 Aug 2015 15:30:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f49.google.com Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 28 Aug 2015 15:30:09 +0000 Received: by qgeh99 with SMTP id h99so33111580qge.0 for ; Fri, 28 Aug 2015 08:30:07 -0700 (PDT) X-Received: by 10.140.133.69 with SMTP id 66mr18130861qhf.12.1440775807276; Fri, 28 Aug 2015 08:30:07 -0700 (PDT) Received: from [192.168.0.26] (97-122-175-227.hlrn.qwest.net. [97.122.175.227]) by smtp.gmail.com with ESMTPSA id k89sm3612597qgk.36.2015.08.28.08.30.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2015 08:30:06 -0700 (PDT) Message-ID: <55E07E7C.3080205@gmail.com> Date: Fri, 28 Aug 2015 15:30:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Brown , Kostas Savvidis , gcc-help@gcc.gnu.org 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> <55E005A7.6000002@westcontrol.com> In-Reply-To: <55E005A7.6000002@westcontrol.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00211.txt.bz2 On 08/28/2015 12:54 AM, David Brown wrote: > 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. The Intel compiler uses attributes (besides pragmas, and other special features for this), so the raw syntax is or can be close to qualifiers (the recommended way to use them is via typedefs). Because the languages requires the qualified and unqualified forms of the same type to have the same representation, an annotation that changes a type's endianness cannot be a qualifier. Objects with different value representations must have distinct types. Although the compiler isn't available for purchase the manuals are now all online: https://software.intel.com/en-us/c-compilers/biendian-support > > 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.) GCC already has experimental support for controlling endianness: https://gcc.gnu.org/ml/gcc/2013-05/msg00249.html There was a discussion back in June of merging it into trunk: https://gcc.gnu.org/ml/gcc/2015-06/msg00126.html I'm not sure if it's been done yet. Martin