Re: Robust detection of endianness at compile time.

["Lee Rhodes" <lee at rhoba dot com>]

Nick, Andrew, Brian, thanks for your replies.

>> "Lee Rhodes" wrote:
>> 
>> There doesn't appear to be a simple and robust (i.e., cross-platform) way
of
>> determining the endianness of the underlying platform at compile-time.
>
> No, there isn't.  And it may not even be possible!  With co-processors,
> which were common with early IBM PCs and are making a slight comeback,
> the endianness of (typically) floating-point may vary with every
> execution.  Yes, using the same binary.  Most language standards
> permit that, and C is one of the few to forbid it even for integers
> (it allows it for floating-point).

I presume you mean an early FP coprocessor, where the CPU issues the
instruction and the binary data sent to the FP unit may have different byte
orders depending on the origin of the data?
  
>> 1.  Since the compiler clearly HAS to know endianess why isn't there a
>> simple, robust way to test for it on all platforms without depending on a
>> header?

> Actually, it doesn't.  It has to do so only for C integers.

Sorry, when I said "compiler" I meant compiler/assembler. Nonetheless, what
do you mean "only for C integers"?  

> In general, you need to know the endianness only when interfacing
> with external entities or protocols with a defined endianness that
> is not your native one.  The most general solution is that you
> analyse the endianness at start-up, create a table, and convert
> when you need to.

Or when performing bit operations on word lengths that are longer than the
native registers of the CPU.  Similar operations could be used to detect
endianness at runtime. E.g., Using a union and addressing the bytes of a 32
bit integer as a byte array.  

> For the past 20 years, such conversion has come essentially for free.
> CPUs are not the bottleneck - memory is.

That is certainly true for the byte shuffle operations for conversion. But a
run-time detection of endianness might require a memory operation.  I would
have to think about it.

###

> "Andrew Haley" wrote:
> 
> Yes, there is.  
> 
> Endianness, like hundreds of other environment quersies needed at
> compile time, is handled by GNU Autoconf.  There's nothing special
> about endianness: it's just another property of the environment you're
> compiling for.

Thanks for pointing me to Autoconf.  I haven't used Autoconf, but I will now
have to study it. Nonetheless, the Macro AC_C_BIGENDIAN appears to only
check for the big endian case, the tacit assumption being that if it ain't
big it must be little.  But what about the PDP/ARM case?  Or is it's weird
layout no longer supported by GCC?

Lee.