[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


--
My regards,

Damien Stewart.


Reply to: