This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 128-bit integer - nonsensical documentation?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]