This macro (and its friend BOOST_LITTLE_ENDIAN) definition appears in boost/detail/limits.hpp. However, that file is included only if boost/limits.hpp does not detect the standard <limits>. Thus, it does not get defined for more standard compilers. The serialization library makes use of this macro (in a test), so I wonder how it works on standard compilers. I could use the ENDIAN macros in some of my code to provide compile time performance options (linux provides something similar). Is it possible to move the ENDIAN macros into some other header so that they are more easily obtained, and also do not force including a limits workaround? I also imagine if they were actually included in more compilations, that they could get checked for correctness and the maintenance of newer platforms would increase. Thanks!
This macro (and its friend BOOST_LITTLE_ENDIAN) definition appears in boost/detail/limits.hpp. However, that file is included only if boost/limits.hpp does not detect the standard <limits>. Thus, it does not get defined for more standard compilers.
The serialization library makes use of this macro (in a test), so I wonder how it works on standard compilers.
I could use the ENDIAN macros in some of my code to provide compile time performance options (linux provides something similar). Is it possible to move the ENDIAN macros into some other header so that they are more easily obtained, and also do not force including a limits workaround?
I also imagine if they were actually included in more compilations, that they could get checked for correctness and the maintenance of newer platforms would increase.
I think this one has come up before: in general there is no way tell what the endianness is without doing a runtime test, there's also the problem that there are more than two orderings possible, for example for 4 byte types the byte ordering could be any of: 1 2 3 4 4 3 2 1 2 1 4 3 3 4 1 2 throw in 8 or 16 byte types, plus floating point types, and things get complicated :-( BTW, if you need the endianness in a test, then it is much easier to determine the byte ordering of a type at runtime than at compile time IMO. Sorry to complicate things for you again! John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:037801c4716d$6d3c9f80$d6390252@fuji...
I think this one has come up before: in general there is no way tell what the endianness is without doing a runtime test,
It would be nice to have a header that does a runtime test in debug mode to make sure the macro is properly defined.
there's also the problem that there are more than two orderings possible, for example for 4 byte types the byte ordering could be any of:
1 2 3 4 4 3 2 1 2 1 4 3 3 4 1 2
Really? I only knew of machines with 2 orderings. What machines use the others? Andrei
On Jul 24, 2004, at 9:02 AM, Andrei Alexandrescu ((See Website for Email)) wrote:
there's also the problem that there are more than two orderings possible, for example for 4 byte types the byte ordering could be any of:
1 2 3 4 4 3 2 1 2 1 4 3 3 4 1 2
Really? I only knew of machines with 2 orderings. What machines use the others?
<http://en.wikipedia.org/wiki/Endianness> says that the PDP machines used 3 4 1 2. -- Darin
On Sat, 24 Jul 2004 11:57:50 +0100 "John Maddock" <john@johnmaddock.co.uk> wrote:
I think this one has come up before: in general there is no way tell what the endianness is without doing a runtime test, there's also the problem that there are more than two orderings possible, for example for 4 byte types the byte ordering could be any of:
Thanks, John! Interesting. I am unaware of the impossibility of it. The only complaints I know of with detecting architecture through macros is having to modify the code for each architecture (ala detail/limits.hpp). It is not the best in the world, but that is mostly because of the maintenance issues.
1 2 3 4 4 3 2 1 2 1 4 3 3 4 1 2
Of the above, I only know of three that are actually in use, and the third (3412) has not been around since the early PDP machines. Of course, I am not familiar with all architectures.
throw in 8 or 16 byte types, plus floating point types, and things get complicated :-(
Again, I think the possibilities outstrip reality, and reality is the only thing that counts here... as long as each architecture has a specific #define that can be detected at compile time. The worst thing is that a particular architecture may not be supported, and a #error can be issued. I imagine architectures are consistent themselves, but something like this would help if that were necessary: #if defined(__i386__) #define BOOST_BYTEORDER_16 12 #define BOOST_BYTEORDER_32 1234 #define BOOST_BYTEORDER_64 12345678 #elif defined(__sparc__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #elif defined(__dinosaur__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #else #error Byte ordering undetected #endif
Again, I think the possibilities outstrip reality, and reality is the only thing that counts here... as long as each architecture has a specific #define that can be detected at compile time. The worst thing is that a particular architecture may not be supported, and a #error can be issued.
I imagine architectures are consistent themselves, but something like this would help if that were necessary:
#if defined(__i386__) #define BOOST_BYTEORDER_16 12 #define BOOST_BYTEORDER_32 1234 #define BOOST_BYTEORDER_64 12345678 #elif defined(__sparc__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #elif defined(__dinosaur__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #else #error Byte ordering undetected #endif
It gets worse. IA-64 supports switching endianness at runtime. :-) See e.g. http://developer.intel.com/design/itanium/manuals/245317.pdf section 4.4: "Accesses to memory quantities larger than a byte may be done in a big-endian or little-endian fashion. The byte order for all memory access instructions is determined by UM in the User Mask register." The user mask can be changed at user-level program's discretion and thus isn't a function of the OS platform used either. I suppose the least incorrect thing to do here would be to define it depending on the default for the particular OS/compiler used. /Mattias
It gets worse. IA-64 supports switching endianness at runtime. :-) See e.g. http://developer.intel.com/design/itanium/manuals/245317.pdf section 4.4: "Accesses to memory quantities larger than a byte may be done in a big-endian or little-endian fashion. The byte order for all memory access instructions is determined by UM in the User Mask register."
The user mask can be changed at user-level program's discretion and thus isn't a function of the OS platform used either. I suppose the least incorrect thing to do here would be to define it depending on the default for the particular OS/compiler used.
Uh! That's definitely um, interesting. Anyone still want these macros? Thanks, John.
On Sun, 25 Jul 2004 11:29:04 +0900, Mattias Flodin <flodin@gmail.com> wrote:
It gets worse. IA-64 supports switching endianness at runtime. :-) See e.g. http://developer.intel.com/design/itanium/manuals/245317.pdf section 4.4: "Accesses to memory quantities larger than a byte may be done in a big-endian or little-endian fashion. The byte order for all memory access instructions is determined by UM in the User Mask register."
The user mask can be changed at user-level program's discretion and thus isn't a function of the OS platform used either. I suppose the least incorrect thing to do here would be to define it depending on the default for the particular OS/compiler used.
FWIW, ARM (+Xscale), Alpha, modern MIPS (Hitachi SH too), Sparc, PowerPC, i960 all have some dual endian ability. Probably others too. Not sure about the run-time configurability like ia64. Regards, Matt Hurd.
Interesting. I am unaware of the impossibility of it. The only complaints I know of with detecting architecture through macros is having to modify the code for each architecture (ala detail/limits.hpp). It is not the best in the world, but that is mostly because of the maintenance issues.
Agreed.
1 2 3 4 4 3 2 1 2 1 4 3 3 4 1 2
Of the above, I only know of three that are actually in use, and the third (3412) has not been around since the early PDP machines. Of course, I am not familiar with all architectures.
OK could be more theoretical then (except on itanium apparently!)
Again, I think the possibilities outstrip reality, and reality is the only thing that counts here... as long as each architecture has a specific #define that can be detected at compile time. The worst thing is that a particular architecture may not be supported, and a #error can be issued.
I imagine architectures are consistent themselves, but something like this would help if that were necessary:
#if defined(__i386__) #define BOOST_BYTEORDER_16 12 #define BOOST_BYTEORDER_32 1234 #define BOOST_BYTEORDER_64 12345678 #elif defined(__sparc__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #elif defined(__dinosaur__) #define BOOST_BYTEORDER_16 21 #define BOOST_BYTEORDER_32 4321 #define BOOST_BYTEORDER_64 87654321 #else #error Byte ordering undetected #endif
That's an even worse maintenance nightmare; at some point there's a cost-benefit trade-off to be made here. John.
participants (6)
-
Andrei Alexandrescu (See Website for Email) -
Darin Adler -
Jody Hagins -
John Maddock -
Matt Hurd -
Mattias Flodin