Re: Let's start a survey on our userbase

On 24/9/25 4:00 am, Jeffrey Walton wrote:
> As someone who has written a lot of SIMD code and cryptographic code
> -- and timed the operations -- I can say it does matter in practice.
> It may be the operation is a nop for one endian, and a byte swap for
> another endian. But it does matter.

The closest I've been to that is porting code that fread() LE data from 
disk and decrypted each long word into BE. In Starcraft MPQ format. I 
ended up customising it with an fread_LE() that read a block of data in 
and then swapped scalars.

To clarify, what I mean by in practice, is in being practical. In the 
outside world. If a coder is targeting the common LE machine he is 
writing for he won't care about writing portable code that is endian 
agnostic. I've seen this run deep by open source code checking for magic 
IDs in long words with backwards text. Now that's putting effort into 
writing anti-portable code. It's also unnecessarily since a compiler can 
code a magic ID in correct order, for any CPU, that is actually source 
readable.

I get amused by people online complaining about big endian network 
order, how it was wrong, how they need to change it because their CPU 
reads in opposite order. Their argument is rather fallacious and 
irrelevant, because if they are using x64 or any x86 in the last 20 
years, then they are using a CPU that natively supports big endian. Time 
to update compilers into this century, as if the compilers aren't 
emitting modern code and using dedicated instructions, then something is 
wrong with the computer world. :-?

> Yeah, it is hit or miss whether Clang and GCC will produce optimal
> code for some endian related patterns, like reading a byte array and
> turning it into a machine word.

Some people have success with it but it can require maximum 
optimisation. I tend to think you shouldn't have to fight with a 
compiler to tell it exactly what you want. This then runs into an XY 
problem, doing X in an attempt for the compiler to produce Y, when you 
should be able to tell it you want exactly Y. I've ran into this. I've 
given up at times on figuring out how to tell the compiler what I want 
and just wrote ASM in place that does exactly what I wanted. But that 
was just some private projects.

I had an issue later when I had code that needed to relocate itself to 
an absolute position and GCC kept optimising away this absolute jump 
from a function pointer and branching to the local function. I ended up 
doing some ASM for the jump but always wanted some cleaner looking C. I 
eventually fixed it with a far attribute which worked. But it took some 
work to find out what it needed to do exactly what my C code had already 
told it to do. And at that point I had to go beyond the language so it 
wasn't portable C anymore. Not that it mattered really as the code 
itself runs as a PPC chain loader. But it would be good if code could be 
written in WYSIWYG fashion for once.