First, such solutions might be good only when you have to read or write data structures which are stored on disk. This because the format is invariant: it stays the same, either little or big endian, whatever is the hardware platform where the software is running.
Second, I personally find the code less readable, and if you apply the same to all parts that need endian handling you can image how bloated it becomes.
Third, the #ifdef BIGENDIAN/LITTLENDIAN allows to encapsulate/isolate the endian differences only to a small part of the code, leaving the rest all the same. This has a clear advantage when you have to maintain it.
Forth, the above #ifdefs allow for much better optimizations, which compilers AND developers can easily exploit, improving performances. I've largely used them when I've written WPython, my CPython fork. Take a look at the slide #12 of my presentation, that you can find here: https://code.google.com/archive/p/wpython/downloads It clearly shows how code can be better organized to take advantage of the specific endianess (the compiler does the rest).
Big endian code is more human friendly. Bytes appear sequentially in memory in the order they are used making text and numbers easier to read when debugging.
Not only for debugging. Big-endian has a clear advantage for string comparisons (or, in general, for "buffers" comparisons) when "less" or "greater" than (equality and inequality are the same) evaluations are needed. That's if you want to do the operation fast (e.g.: loading more than one byte a the time for the comparison); this is also the reason why Intel introduced specific instructions for string comparisons. Quote:
It is also easier to change programs to use different data sizes. For example, let's say we are loading 32 bits at a time and then change the program to load 64 bits at a time. The order of the data doesn't change with big endian. Little endian requires knowing the sizes of all data accesses and reordering the data appropriately if they change.
Strange: I find the exact opposite opinion. To me if I've to extend a little-endian data type from 32 to 64 bit, then the lowest 4 bytes remain exactly the same, and only 4 additional bytes should be added just after them. No size is needed, and eventually pointers remain exactly the same (they always point to the LSB, either for 32 or 64-bit data). Whereas for big endian it's the opposite.
But maybe I got it wrong. Can you give some examples? Quote:
Little endian made sense when fetching the least significant bytes was important for multi-precision integer math of data in memory with no caches but those days are long gone.
Hum. Disagree. It's still common, even with caches. At least you don't have to adjust pointers to start from the beginning (LSB), and going "back" to the MSB, which might cause problems to the cache-prefetching hardware (it's easier to "predict" data accesses which will follow in memory). Quote:
It looked like big endian would win at one point but little endian has come back now and big endian is now near extinction. Fewer and fewer software and hardware developers are caring about supporting big endian.
Indeed, and that's because all major/mainstream architectures embraced little-endian. It doesn't make sense to continue to support big-endian, at least from a cost/benefit PoV.
That was interesting. Sorry to carry this thread further off course, but from the first link, does anyone know anything about this?
Quote:
John von Neumman's design doc from the second world war for EDVAC, which very clearly laid out that the plan was to have 32-bit little endian two's complement integers.
_________________ "Unix is supposed to fix that." -- Jay Miner
Well, we mentioned X5000 and AmigaOS being gone from the site, so...
This wouldn't be the first time A-Eon/AmigaKit were "busy" and difficult to contact. I can't imagine that supporting their existing AmigaOne customers could be a legal liability due to the current lawsuit. My comment about the 1222 delays above was a sarcastic joke by the way.
tygre Quote:
I just stumbled onto these blog posts (via Hacker News), very interesting explanations and discussions of endianness!
There are some good points but using octal shift counts and decimal masks are cringe worthy instead of "elegant". The poorly chosen octal designation character in C doesn't help but neither does the rare use of octal any more. In my opinion, it's usually better to use decimal shift counts and hexadecimal masks for readability.
It is unclear if there is a problem "The Byte Order Fiasco" is trying to avoid by recommending all unsigned values when shifting. It could be clearer that i is an unsigned integer even though the "data stream has a little-endian-encoded 32-bit integer". The code relies on the compiler recognizing a pattern and converting it into one 32 bit load or it will do 4 byte loads with shifts and or instructions. There are multiple variations of this code the compiler has to recognize which some compilers will not be able to do especially older ones which are commonly used for the Amiga. Better disassemble your executable to make sure the code is using a single load but then it helps to have more readable assembler code like the 68k. While it is portable because it reads bytes at a time, it is dependent on compilers recognizing code patterns to make it optimal. If the code is not recognized then it is more optimal to use the GCCism __builtin_bswap32(). I wrote a universal link library for compilers which don't support it like vbcc although there were only 137 downloads which is not enough users to even properly test it.
Big endian code is more human friendly. Bytes appear sequentially in memory in the order they are used making text and numbers easier to read when debugging. It is also easier to change programs to use different data sizes. For example, let's say we are loading 32 bits at a time and then change the program to load 64 bits at a time. The order of the data doesn't change with big endian. Little endian requires knowing the sizes of all data accesses and reordering the data appropriately if they change. Little endian made sense when fetching the least significant bytes was important for multi-precision integer math of data in memory with no caches but those days are long gone. It looked like big endian would win at one point but little endian has come back now and big endian is now near extinction. Fewer and fewer software and hardware developers are caring about supporting big endian. This is not good for the Amiga unless deciding to break compatibility and create a little endian Amiga which AROS has tried with no noticeable gain in market share.
Last edited by matthey on 11-May-2021 at 12:42 AM. Last edited by matthey on 11-May-2021 at 12:41 AM.
Joined: 5-Oct-2003 Posts: 896
From: Hattiesburg, MS
@tygre
Thanks; that's very interesting.
_________________ I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.
18 crawler(s) on-line.
144 guest(s) on-line.
1 member(s) on-line.
cdimauro 
