OS image with Big Endian architecture?
Hi, for my development testing purposes I need to run an OS using Big Endian byte architecture. Any chance I could find/deploy such an image on Linode? Thank you!
6 Replies
The CPU is what determines which byte order a computer uses rather than the OS. I checked and both our Intel and AMD hosts use little endian byte order.
On a Linux machine, you can run this command to see what byte order you're using:
lscpu | grep "Byte Order"
What are you testing that's dependent on the endianness of the CPU? The only thing I can think of where such a thing would be necessary would be network interface drivers. Doing such a thing would be very problematic in a virtual environment like Linode (all the "hardware" is virtual…set up by the Xen hypervisor).
Most of the inexpensive ARM 7 and later chips used in the hobbyist board systems (see http://armbian.com) can operate in either big- or little-endian mode…governed mostly by the tool chain you use to build your software. This hardware is really inexpensive and pretty decently capable. This might be an option for you.
Of course, if you're working on a driver, this wouldn't work for you at all as you're unlikely to be able to install your hardware in an ARM hobbyist system.
-- sw
@Loni Yes, I've built up most of the images on the list and ran that command and a couple others to my continual disappointment :) Thank you for confirming this is not likely to vary.
@stevewi Hi! Thanks for the detailed response. It's for an assignment in a C programming curriculum where I'm to clone readelf -h among other commands and I really wanted access to a native environment where Endianness and 32/64 bit architecture of the binaries would be different from the 64 little endian I'm working with on Ubuntu :)
Given that this is for an assignment and you have no access to a big endian machine, what I would do is to program the difference as you understand it:
if (endianness == little)
{
...do little endian stuff...
} else {
...do big endian stuff...
}
wherever you need to do it. Run your program against a known case (say every executable in /bin and /sbin); use the debugger to artificially alter the program flow on some of them; and hope your professor can't come up with a case that will break your program ;-) FWIW, since professors are basically lazy creatures who depend mightily on the slave labor provided by grad students and everyone shares the same universe, I'll bet you a donut s/he won't be able to find such a case :-) The Harry Callahan query about Do you feel lucky? and the number of shots he fired applies here…
The only big endian architectures I've ever encountered are the 16-bit Moto 680x0, the PowerPC (IBM), SPARC (Sun/Oracle) and PA-RISC (HP). All but the Moto migrated to 64-bit bi-endianness in later iterations. All of them are extinct.
-- sw
Yeah, that might be a little too simplistic for my educational purposes. Regardless of my professors' grading mechanisms (he has sample binaries generated for various architectures and does a "diff" on stdout/err of my readelf vs system) and, I wanted to actually parse the byte sequences manually with my C code to get a visceral experience.
I was hoping in this age of cloud virtualization that would be no prob, but alas… :)
I'm grateful to get clarity that it is not OS dependent but machine architecture dependent, but also might have assumed virtualization of the machine is possible.
