"[3B2] Fairly normal architecture, except it is big endianian, unlike most computers nowadays. The char datatype is unsigned by default."
That sounds like any SGI, or Sun, and although they're mostly gone there's still the Power series from IBM (runs AIX), and the only reason to use the expression ".. unlike most computers nowadays" is by counting the sheer number of Intel, AMD and ARM chips in use. Of course those numbers are overwhelming - ARM alone sells billions - but it's not like big endian is some obscure old concept in a dusty corner. (The irony is that ARM can be used in both BE and LE modes, by setup).
Anyway, at work I have to write all the code so that it runs on BE as well as LE architectures. BE is alive and well.
Big-endian arm is pretty rare -- it's basically a niche requirement for markets like embedded network hardware where there is a lot of pre-existing code that assumes big-endian because it used to be run on m68k or mips. Most network protocols are big-endian on the wire, so on a BE host if you forget a htons() or ntohs() call it all still works; auditing a legacy codebase for that kind of bug in order to port it to a LE host is painful. But any general-purpose-ish Arm system (intended for running Linux or Android or Windows) will be LE.
Fun fact: the optimized string library for the original ARM1176 raspberry pi had a bonkers implementation of memcmp() which used the SETEND insn to temporarily switch to bigendian, because on that core setend is only 1 cycle and it saved an insn or two later. (On newer cores setend is a lot more expensive and the trick doesn't work.)
Yes, PPC is also switchable, as is MIPS (my R4000 SGI boxes are big endian, while my R4000 Jazz box (Olivetti M700-10) is little endian).
https://en.wikipedia.org/wiki/Endianness#Bi-endianness lists ARM >= v3, PowerPC, Alpha, SPARC V9, MIPS, PA-RISC, SuperH SH-4 and IA-64 as bi-endian (can be configured as wither). MIPS is still used a lot in routers. I don't know if the MIPS-compatible PIC32 is also bi-endian - there's maybe no reason it should be.
About ARM, I don't think I have run into any BE-mode ARM systems in a while, but I do recall using big-endian gcc versions for something in the past. And apparently some folks are running Cubieboards in big endian mode (if that's common or not for Cubieboards/Cubietrucks I don't know).
Yeah, network protocols will keep BE alive if nothing else - and yet, the Power 7 systems I'm coding for at the moment are big endian and IBM won't change that in the reasonably long term.
>If only because network protocols are generally BE.
I think a big part of this is that, until x86 conquered all, big-endian was far more common than little-endian. So when all those "foundational" protocols were originally designed, it was little-endian that would have been the bizarre choice.
That sounds like any SGI, or Sun, and although they're mostly gone there's still the Power series from IBM (runs AIX), and the only reason to use the expression ".. unlike most computers nowadays" is by counting the sheer number of Intel, AMD and ARM chips in use. Of course those numbers are overwhelming - ARM alone sells billions - but it's not like big endian is some obscure old concept in a dusty corner. (The irony is that ARM can be used in both BE and LE modes, by setup). Anyway, at work I have to write all the code so that it runs on BE as well as LE architectures. BE is alive and well.