4 ms·

PowerPC "supports" both, but I believe it's typically run in big endian mode. Same with MIPS AFAIK. (Mini rant: CPU people seem to think that you can avoid end

by mort96 1y ago

PowerPC "supports" both, but I believe it's typically run in big endian mode. Same with MIPS AFAIK. (Mini rant: CPU people seem to think that you can avoid endianness issues by just supporting both little and big endian, not realizing the mess they're creating higher up the stack. The OS's ABI needs to be either big endian or little endian. Switchable endianness at runtime solves nothing and causes a horrendous mess.)

fredoralive 1y ago
Linux has mostly transitioned to little endian on PowerPC. AIX remains big endian.
- mghackerlady 1y ago
  Also, Net and Open BSDs support big endian PowerPC (NetBSD supports big endian arm even)
  - yjftsjthsd-h 1y ago
    > NetBSD supports big endian arm even AFAIK, this is probably the easiest way to test BE on hardware (if you need that for some reason) - NetBSD on a Raspberry Pi running in BE mode is easy to use. (EDIT: Actually the more important thing is that it's cheap and easy to acquire)
  - mort96 1y ago
    What's the reason someone would willingly choose to run a big endian ARM OS?
    - wahern 1y ago
      To use big endian on real-world systems. And one of the reasons to use big endian is because diversity helps to find bugs in code. A bug that might result in a hidden off-by-one on little endian might crash on big endian.
      - typpilol 1y ago
        Wouldn't that only matter if the bug has no affect on little endian? Otherwise you don't need the other endian to confirm it? Or are you saying to test their software before it goes out to big endian devices, which doesn't answer the question as to why someone would want to use it on those end devices?
        wolrah 1y ago
        > Wouldn't that only matter if the bug has no affect on little endian? I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.
- mort96 1y ago
  Oh, that's excellent news! The more little endian, the better.
  - sim7c00 1y ago
    you must be the guy who thought of middle endian
    - voxadam 1y ago
      I hear that middle endian is ideal endainness when implementing middle-out compression.
- bonzini 1y ago
  I think the kernel remains big endian. Only userspace has a brand new little-endian ABI.
qdotme 1y ago
You could actually support both at runtime with both ABIs being available. This is done routinely on x86_64 with x86 ABI for compatibility (both sets of system libraries are installed), for a while I used to run 3 ABIs (including x32 - the 64bit with short pointers) for memory savings with interpreted languages. IRIX iirc supported all 4 variants of MIPS; HP-UX did something weird too! I’d say for some computations one or the other endianness is preferred and can be switched at runtime. Back in the day it also saved on a lot of network stack overheads - the kernel can switch endianness at will, and did so.
- mort96 1y ago
  Are you advocating that Linux systems on PowerPC should have two variants of every single shared library, one using the big endian ABI for big endian programs and one using the little endian ABI for little endian programs? Because that's how 32-bit x86 support is handled. There are two variants of every library. These days, Linux distros don't even provide 32-bit libraries by default, and Ubuntu has even moved to remove most of the 32-bit libraries from their repositories in recent years. Apple removed 32-bit x86 support entirely a few years back so that they didn't have to ship two copies of all libraries anymore. What you're proposing as a way to support both little and big endian ABIs is the old status quo that the whole world has been trying (successfully) to move away from for the past decade due to its significant downsides. And this is to say nothing of all the protocols out there which are intended for communication within one computer and therefore assume native endianness.
  - qdotme 1y ago
    There are downsides. Unsure if significant vs negligible. And same in terms of “internal” protocols - that essentially goes against the modularity (and while in the past there were good reasons to get away from modularity in pursuit of performance, darn, baudline.com of 2010 works amazingly well and is still in my toolbox!) Big advantage of the “old ways” was the cohesion of software versions within a heterogenous cluster. In a way I caught the tail end of that with phasing out of MIT Athena (which at the time was very heterogeneous on the OS and architecture side) - but the question is, well, why. Our industry is essentially a giant loop of centralizing and decentralizing, with advantages in both, and propagation delays between “new ideas” and implementation. Nothing new, all the economy is necessarily cyclic so why not this. I’d argue that in the era of inexpensive hardware (again) and heterogenous edge compute, being able to run a single binary across all possible systems will again be advantageous for distribution. Some of that is the good old cosmopolitan libc, some of that is just a broad failure of /all/ end-point OS (which will brood its own consequences) - Windows 11, OSX, Androids etc..
zamalek 1y ago
Linus hates big endian, and has some choice words to say about switchable [1]. This incarnation of Linus is certainly my favorite :) [1]: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/t/#mce138059dc56014643bbda330810183031ef5c06 https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6W...
- galangalalgol 1y ago
  Linux still supports BE for several targets, his point, I think, was that no one ises risc-v as BE except maybe in an academic setting. I don't think llvm or gcc will even target BE, so not sure how they were going to conpule those mods anyway
- mort96 1y ago
  Linus hates introducing a ton of complexity and opportunity for bugs for no upside. Pre-emptively adding runtime endianness switching to RISC-V when there's not even market demand for it 100% falls into that category. Adding runtime endianness switching to the RISC-V ISA also falls into that category. Supporting big endian for big-endian-only CPUs does not fall into that category.
  - zamalek 1y ago
    The first line in the email that I linked is pretty unambiguous: > Oh Christ. Is somebody seriously working on BE support in 2025? Followed by Eric: > And as someone who works on optimized crypto and CRC code, the arm64 big endian kernel support has always been really problematic. It's rarely tested, and code that produces incorrect outputs on arm64 big endian regularly gets committed and released. It sometimes gets fixed, but not always; currently the arm64 SM3 and SM4 code produces incorrect outputs on big endian in mainline BE support is unambiguously best-effort (which is none in some cases). No, the Kernel does not take BE seriously. Not sure why I have to quote from the mailing list when the URL was a significant portion of my comment text - it directly contradicts your assertion on multiple fronts.
    - 1y ago
sumtechguy 1y ago
Think windows only supported one machine type declared with big endian from what I can see in the docs with the PE format. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types https://learn.microsoft.com/en-us/windows/win32/debug/pe-for... There may have been others in the NE format. Also pretty sure the older power pc mac 7/8 machines were big endian.

by mort96 1y ago

fredoralive 1y ago

Linux has mostly transitioned to little endian on PowerPC. AIX remains big endian.

mghackerlady 1y ago
Also, Net and Open BSDs support big endian PowerPC (NetBSD supports big endian arm even)
- yjftsjthsd-h 1y ago
  > NetBSD supports big endian arm even AFAIK, this is probably the easiest way to test BE on hardware (if you need that for some reason) - NetBSD on a Raspberry Pi running in BE mode is easy to use. (EDIT: Actually the more important thing is that it's cheap and easy to acquire)
- mort96 1y ago
  What's the reason someone would willingly choose to run a big endian ARM OS?
  - wahern 1y ago
    To use big endian on real-world systems. And one of the reasons to use big endian is because diversity helps to find bugs in code. A bug that might result in a hidden off-by-one on little endian might crash on big endian.
    - typpilol 1y ago
      Wouldn't that only matter if the bug has no affect on little endian? Otherwise you don't need the other endian to confirm it? Or are you saying to test their software before it goes out to big endian devices, which doesn't answer the question as to why someone would want to use it on those end devices?
      - wolrah 1y ago
        > Wouldn't that only matter if the bug has no affect on little endian? I don't know whether this logic applies to this specific sort of bug, but there is a long history of bugs that "don't matter" combining with other bugs to become something that matters. Therac-25 was a bug that didn't matter on the hardware it was developed for, but then the software that "worked fine" got repurposed for another hardware platform and people died. If there's an easy way to identify an entire class of bugs it seems like a good idea to do it.
mort96 1y ago
Oh, that's excellent news! The more little endian, the better.
- sim7c00 1y ago
  you must be the guy who thought of middle endian
  - voxadam 1y ago
    I hear that middle endian is ideal endainness when implementing middle-out compression.
bonzini 1y ago
I think the kernel remains big endian. Only userspace has a brand new little-endian ABI.

qdotme 1y ago

You could actually support both at runtime with both ABIs being available. This is done routinely on x86_64 with x86 ABI for compatibility (both sets of system libraries are installed), for a while I used to run 3 ABIs (including x32 - the 64bit with short pointers) for memory savings with interpreted languages. IRIX iirc supported all 4 variants of MIPS; HP-UX did something weird too! I’d say for some computations one or the other endianness is preferred and can be switched at runtime. Back in the day it also saved on a lot of network stack overheads - the kernel can switch endianness at will, and did so.

mort96 1y ago
Are you advocating that Linux systems on PowerPC should have two variants of every single shared library, one using the big endian ABI for big endian programs and one using the little endian ABI for little endian programs? Because that's how 32-bit x86 support is handled. There are two variants of every library. These days, Linux distros don't even provide 32-bit libraries by default, and Ubuntu has even moved to remove most of the 32-bit libraries from their repositories in recent years. Apple removed 32-bit x86 support entirely a few years back so that they didn't have to ship two copies of all libraries anymore. What you're proposing as a way to support both little and big endian ABIs is the old status quo that the whole world has been trying (successfully) to move away from for the past decade due to its significant downsides. And this is to say nothing of all the protocols out there which are intended for communication within one computer and therefore assume native endianness.
- qdotme 1y ago
  There are downsides. Unsure if significant vs negligible. And same in terms of “internal” protocols - that essentially goes against the modularity (and while in the past there were good reasons to get away from modularity in pursuit of performance, darn, baudline.com of 2010 works amazingly well and is still in my toolbox!) Big advantage of the “old ways” was the cohesion of software versions within a heterogenous cluster. In a way I caught the tail end of that with phasing out of MIT Athena (which at the time was very heterogeneous on the OS and architecture side) - but the question is, well, why. Our industry is essentially a giant loop of centralizing and decentralizing, with advantages in both, and propagation delays between “new ideas” and implementation. Nothing new, all the economy is necessarily cyclic so why not this. I’d argue that in the era of inexpensive hardware (again) and heterogenous edge compute, being able to run a single binary across all possible systems will again be advantageous for distribution. Some of that is the good old cosmopolitan libc, some of that is just a broad failure of /all/ end-point OS (which will brood its own consequences) - Windows 11, OSX, Androids etc..

zamalek 1y ago

Linus hates big endian, and has some choice words to say about switchable [1]. This incarnation of Linus is certainly my favorite :) [1]: https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA@mail.gmail.com/t/#mce138059dc56014643bbda330810183031ef5c06 https://lore.kernel.org/lkml/CAHk-%3DwgYcOiFvsJzFb%2BHfB4n6W...

galangalalgol 1y ago
Linux still supports BE for several targets, his point, I think, was that no one ises risc-v as BE except maybe in an academic setting. I don't think llvm or gcc will even target BE, so not sure how they were going to conpule those mods anyway
mort96 1y ago
Linus hates introducing a ton of complexity and opportunity for bugs for no upside. Pre-emptively adding runtime endianness switching to RISC-V when there's not even market demand for it 100% falls into that category. Adding runtime endianness switching to the RISC-V ISA also falls into that category. Supporting big endian for big-endian-only CPUs does not fall into that category.
- zamalek 1y ago
  The first line in the email that I linked is pretty unambiguous: > Oh Christ. Is somebody seriously working on BE support in 2025? Followed by Eric: > And as someone who works on optimized crypto and CRC code, the arm64 big endian kernel support has always been really problematic. It's rarely tested, and code that produces incorrect outputs on arm64 big endian regularly gets committed and released. It sometimes gets fixed, but not always; currently the arm64 SM3 and SM4 code produces incorrect outputs on big endian in mainline BE support is unambiguously best-effort (which is none in some cases). No, the Kernel does not take BE seriously. Not sure why I have to quote from the mailing list when the URL was a significant portion of my comment text - it directly contradicts your assertion on multiple fronts.
  - 1y ago

sumtechguy 1y ago

Think windows only supported one machine type declared with big endian from what I can see in the docs with the PE format. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types https://learn.microsoft.com/en-us/windows/win32/debug/pe-for... There may have been others in the NE format. Also pretty sure the older power pc mac 7/8 machines were big endian.