@ppcamiga1

My point in the examples is porting software to AmigaOS. Software that is written to be non-portable in a portable language. Some software is written to assume a specific byte order and such software will break if not fixed even after it managed to compile.

@ppcamiga1

Yes, "holy war" against ppc by AROS developers.
That's why there's a ppc version of AROS and why AROS developers have contributed toward ppc and 68k Amiga based systems.
Because of crusades and holy wars against ppc.

Have you stopped taking your meds?

@ppcamiga1 @hypex

Although I like the example of 0xCAFEBABE

Here is a very interesting article on the (dis)advantages of Big vs. Little Endian with diverse criteria. At the end, it seems that Little Endian is more advantageous...

PS. I can't understand why some must bring some dubious "historical" figure in a technical discussion about Endianness! Let's stay on topic and technical!

Last edited by tygre on 20-Aug-2021 at 11:39 PM.
Last edited by tygre on 20-Aug-2021 at 11:37 PM.
Last edited by tygre on 20-Aug-2021 at 11:36 PM.

_________________
Tygre
Scientific Progress Goes Boing!

tygre Quote:

Here is a very interesting article on the (dis)advantages of Big vs. Little Endian with diverse criteria. At the end, it seems that Little Endian is more advantageous...

My reassessment of article assessment.

Big Endian Advantages
human readable (naturalness)
two's complement signed integer and floating point detect sign
searching/sorting unknown length datatypes (sorting unknown blobs)
network order (convention) and old order (68k, PPC, SPARC, MIPS, SuperH)
arbitrary precision integer division and floating point fetch and calc (mostly outdated advantage)

Little Endian Advantages
current most used order (x86, x86-64, ARM, RISC-V)
recasting a pointer
detect odd/even integer and floating point (less common than sign detect)
variable/arbitrary length encoding advantage (combined 2 similar categories)
arbitrary precision integer add and subtract fetch and calc (mostly outdated advantage)

Arbitrary precision addition and subtraction are *not* a problem with big endian (68k uses ADD+ADDX for example). There used to be a fetch advantage for what data was needed first but now larger datatypes, wider ALUs and caches have practically eliminated any advantages.

Last edited by matthey on 21-Aug-2021 at 01:21 AM.
Last edited by matthey on 21-Aug-2021 at 01:21 AM.

@tygre

Interesting article that has nothing to do with Amiga.
Most of Amiga software is big endian.
And expect data in os and other software in big endian format.
So Amiga was big endian, is big endian and will be big endian.

@matthey

My take on this.

Quote:

Big Endian Advantages human readable (naturalness) two's complement signed integer and floating point detect sign searching/sorting unknown length datatypes (sorting unknown blobs) network order (convention) and old order (68k, PPC, SPARC, MIPS, SuperH) arbitrary precision integer division and floating point fetch and calc (mostly outdated advantage)

In practical use it goes deeper than being human readable. It's also the code order. In a machine code dump it is exactly how the CPU will see it with WYSIWYG. This means text can be read and written directly. Magic bytes of any size can be read and written. Multi size vectors can be read and written. Binary data written by 32-bit CPU can be read in by 64-bit CPU. Such as two 32-bit words read in as one 64-bit word. Interoperable between different CPU word sizes.

Quote:

Little Endian Advantages current most used order (x86, x86-64, ARM, RISC-V) recasting a pointer detect odd/even integer and floating point (less common than sign detect) variable/arbitrary length encoding advantage (combined 2 similar categories) arbitrary precision integer add and subtract fetch and calc (mostly outdated advantage)

Wins popularity contest. Becomes illogical when data such as R5G5B5 is forced to be split into reverse order which breaks bitfields. Recasting a pointer may help in ASM but don't see advantage in high level. Text and magic bytes cannot be directly read and written, with programmers doing strange operations looking for backward text, rather than writing readable portable code. Binary data written by 32-bit CPU cannot be read in by 64-bit CPU. Such as two 32-bit words cannot be read in as one 64-bit word. Not iteroperable between different CPU word sizes.

@fishy_fis

little almost no support for ppc vs many years of attack and lies about ppc.

fishy_fis have you stopped taking your meds?

@ppcamiga1

What attacks and lies about ppc?
Can you name a single one?
If its been going on for years there must be at least one you can name?

Also, AROS is open source, as you yourself mentioned. Anyone can contribute if interested.
If there's not many contributions specifically for ppc then that is due to a lack of people interested, not of of some imagined (in your head only) conspiracy against ppc.

There's also the fact that code in general has been reused by ppc focused OSes.
How is that not contributing?

And Im not the one spewing crap or constantly spouting delusions that only exist in my head.
That would be you.
Ergo the inquiry about whether or not youve been taking your meds.
Because you're carrying on like a froot loop.

@fishy_fis

Please, do not feed that troll. For his trolling actions he is being regularly blocked on other forums, especially in Poland. I count days until it happens here, too ;)

@Hypex @matthey

Thanks for your comments!

But when using "high level" programming language, Big vs. Little Endian should not matter, right? Even with C... the compiler should take care of it?

Big vs. Little Endian should matter only? when the code must deal encoding/decoding data following some protocols, which may be Big or Little Endian, shouldn't it?

_________________
Tygre
Scientific Progress Goes Boing!

@tygre

Quote:

Even with C... the compiler should take care of it?

it does not take care of it, that’s the problem, instead we use macros, lookup tables and inline assembler code, precompiler #if's and so on.

int is int as long as its in memory, and as long hardware use same endianness.
short is short as long as its in memory, and as long hardware use same endianness.

Some times you work on 32bit data, and you have ALPHA, RED, GREEN, BLUE store in 32bit data, now need to access the RED, but it depends on endianness, where it is in 32bit data. Some times its 16bit data, R 5bit G 6bit B 5bit – RRRRRGGG GGGBBBBBB – swapped and it becomes GGGBBBBB RRRRRGGG, a total mess, anyway lookup tables are useful hare, but its is pain in the ass.

It effects files, when you save, and load data as well.

Is there language that can solve it, yes you make swap class, in C++, however it not something you do, because your conversion most often needs to light wight.

If added support for beInt32, leint32 to C and C++ language it be most useful featured added to it, some of new stuff in C++11, C++12 will never be used, it's just more bloat.

Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:36 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:28 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:26 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:24 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:17 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:16 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:11 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 07:11 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@fishy_fis

You fishy_fis are the one that spewing crap or constantly spouting delusions that only exist in your fishy_fis head.

As for aros. aros for x86 was mistake.
aros x86 was not source and binary compatible with Amiga OS.
And at the same time this aros x86 has not memory protection.
Nobody need this crap.

aros devs should start from 68k or ppc version.
From something with integration with 68k Amiga software.
Made good open source reimplementaion of Amiga gui and graphics.
Then swithc to unix.

@tygre

Big vs. Little Endian should matter only?
It is most important thing in making software for Amiga.

@tygre

Quote:

But when using "high level" programming language, Big vs. Little Endian should not matter, right? Even with C... the compiler should take care of it?

Right, it shouldn't matter. The compiler should take care of it, in the case I was talking about, with making a recast.

And if code is isolated, such as it doesn't need to read in or export binary data, then endian wouldn't matter.

Even a magic ID, such as "TEXT" to give an example, can be encoded in 32 bits so that the compiler creates the proper byte order that works on any endian.

Quote:

Big vs. Little Endian should matter only? when the code must deal encoding/decoding data following some protocols, which may be Big or Little Endian, shouldn't it?

That's right. It tends to be with data structures. And files coded in little endian. And in cases where the coder didn't write proper portable code and assumed specific byte order. Such an assumption goes deeper than high level coding and even if true in most cases, it's bad form to assume low level specifics when writing high level code, as well as not being portable.

Compilers tend to lack support for specifying data encoding which would help in a lot of cases. They can support built in conversions but it doesn't always help and doesn't always work. For example, GCC has a built in endian swap, but it's useless on PPC because it can't swap inside a register, unlike x86. But, it can do it when reading/writing to memory, which is where it's most important. However, GCC is designed to do it from a value, not a pointer so the operation suffers on PPC.

And so, it makes it hard to deal with it and unless the code is written to deal with it, by using macros for every read or write that can also be annoying, then needing to fix code to be endian aware or agnostic can be a ton of work.

Last edited by Hypex on 27-Aug-2021 at 10:58 AM.