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.
Re: Cloanto acquire Amiga Inc Trademark Posted on 13-May-2021 7:02:12
Yet another time yet another idiot start the same old shit "switch to x86" again. Amiga was made as big endian computer. In 1985 every civil 32 bit cpus was big endian so Amiga was made big endian. 32 bit big endian cpu is one and only thing from original Amiga that cannot be changed. Everything may be changed in Amiga but not cpu to little endian. So no x86, risc-v, most of arm. cpu change to little endian breaks compatybility. after change to little endian it will be no more good old Amiga that we know and love.
Re: Cloanto acquire Amiga Inc Trademark Posted on 13-May-2021 7:22:09
Yet another time yet another idiot start the same old shit "switch to x86" again.
Whereas "smart" guys aren't even able to understand the writings, since nobody claimed it. Quote:
Amiga was made as big endian computer.
Only by case. Quote:
In 1985 every civil 32 bit cpus was big endian
Proof about that?
But, more important: does it matter? Quote:
so Amiga was made big endian.
False: it's only because 68K was chosen. Quote:
32 bit big endian cpu is one and only thing from original Amiga that cannot be changed. Everything may be changed in Amiga but not cpu to little endian. So no x86, risc-v, most of arm. cpu change to little endian breaks compatybility. after change to little endian it will be no more good old Amiga that we know and love.
The only correct thing that you said.
But you know what? Amiga died 27 years go. It's a retro-platform. And nobody cares about changing it. People just enjoys it as it is, and the same happens for any other retro-platform.
Re: Cloanto acquire Amiga Inc Trademark Posted on 13-May-2021 15:46:27
Some people in this community do not accept reality. It is their problem. Reality do not change because for example cdimauro do not accept it. It is simple. Amiga was made big endian. And after switch to litte endian it will be no longer at the same time source and binary compatible.
Amiga is not retro. It is not important how much computers where sold after Commodore. It is important how Amiga was made.
Re: Cloanto acquire Amiga Inc Trademark Posted on 14-May-2021 10:41:11
And then to M1 The real problem is that AmigaOS 4.1 is so outdated and primitive that it is not really an alternative to modern OSes. Back then it was better but how can it compete now? it’s too late. If it was open sourced maybe some talented coders could work on it an break the damn compatibility to be able to have something better.
Last edited by kamelito on 14-May-2021 at 02:17 PM. Last edited by kamelito on 14-May-2021 at 02:16 PM.
Re: Cloanto acquire Amiga Inc Trademark Posted on 14-May-2021 15:42:29
True but latest MacOSX does not support MC680x0 programs nor does it support PowerPC programs, they dropped all support, so if you own old program a few decades back you can’t use these programs, that might be OK on Apple hardware, but I don’t think its ok in Amiga land to cut off your leg (cut off old software), to get a leg replacement (software replacement), because no one is making leg replacements (software replacements) for really old stuff. AmigaOS is retro platform if you like it or not, if want to have security, then you use different OS, like Windows or Linux, AmigaOS does not even have up to date virus killer software pack, and databases are not kept up to-date.
Some people in this community do not accept reality. It is their problem.
I fully agree on this. Quote:
Reality do not change because for example cdimauro do not accept it.
I fully disagree on this, because all that I've reported is fully-compliant with the reality.
But are free to quote me and show me (with FACTs: not your non-sense) where it's no the case, if you think differently. Quote:
It is simple. Amiga was made big endian.
Yes, and so? Quote:
And after switch to litte endian it will be no longer at the same time source and binary compatible.
It would miss only binary compatibility.
Source compatibility is kept as long as sources are correctly written by coders. Again, AROS is a clear proof here. And, again, you have no clue of what you're talking about. Quote:
Amiga is not retro. It is not important how much computers where sold after Commodore.
It's the exact opposite when we're talking of retro-platforms: it matters.
Any number? New models? Please, list them. Quote:
It is important how Amiga was made.
It WAS important how Amiga WAS made. It was important AT THAT TIME.
Certainly NOT now, because computing took different paths.
Finally and quoting Rose: "still eagerly waiting your big brain answer to #1290.".
OlafS25 wrote: @ppcamiga1
How do you explain how Apple could switch from 68k to PPC and then X86?
And now ARM.
That's because the o.s. had a better design, which didn't exposed internals or allowed for too low-level stuff / control to the user. Properly abstracted APIs & o.s. structures are the key things here.
At least for desktop/server/et similar markets.
For embedded markets it's the opposite: it's an advantage. As clearly proved by many projects which used the Amiga o.s..
Re: Cloanto acquire Amiga Inc Trademark Posted on 15-May-2021 1:11:58