This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: 128-bit integer - nonsensical documentation?
- From: David Brown <david at westcontrol dot com>
- To: Martin Sebor <msebor at gmail dot com>, Kostas Savvidis <ksavvidis at gmail dot com>, <gcc-help at gcc dot gnu dot org>
- Date: Fri, 28 Aug 2015 08:54:31 +0200
- Subject: Re: 128-bit integer - nonsensical documentation?
- Authentication-results: sourceware.org; auth=none
- References: <1B1111BE-E274-4C80-8189-22B78D77647A at gmail dot com> <55DDAD64 dot 3040607 at westcontrol dot com> <55DDE30A dot 1080506 at gmail dot com> <55DEB83C dot 5010106 at westcontrol dot com> <55DF2814 dot 3050206 at gmail dot com>
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