Porting GHC: A Tale of Two Architectures
chiark.greenend.org.uk
chiark.greenend.org.uk
It did reveal an actual bug in [edit: a branch of] qemu. It wasn't emulating the aarch64 RET xN instruction correctly. Apparently no other software in the whole of Linux uses this strange variant of RET.
I expect most code generators use BR for "jump to destination in arbitrary register" -- BR and RET behave identically except for RET providing a hint for branch prediction and for debuggers that it's a return-from-subroutine rather than a random jump; so "RET LR" is really common and "RET <any other register>" is kind of weird.
https://git.fedorahosted.org/cgit/fedora-ocaml.git/tree/asmr...
What do you think? Looks like a return to me, albeit using an unusual register. Note that this code is especially speed critical because every time OCaml calls a C function that could allocate GC'd memory, it has to go through this function.
Googling around it seems the use for little-endian PPC is to be more easily compatible with GPUs. Is there really a market for running GPU computing with PPC64 CPUs?
• Growing interest in running entire OS in little-endian mode – Ease porting of programs from other architectures – Ease porting of programs which access files containing LE binary data – Ease communication with GPUs • New OpenPower Consortium – IBM, Google, Tyan, Nvidia, Mellanox
Also, see [1].
[0] http://www.linux-kvm.org/wiki/images/7/70/Kvm-forum-2013-Mac... [1] https://www.ibm.com/developerworks/community/blogs/fe313521-...
Where has the demand come from to start supporting little-endian mode suddenly? I assume the existence of a Debian/Ubuntu port is evidence of such demand.
I found a Debian discussion on this and the only reasons presented were GPU computing and porting apps that assume little-endian. I assume the GPU computing is the big reason. As we move to unified memory architectures between CPU and GPU they need to both use the same endianness and I guess GPUs are usually little-endian to match x86.
As others note that IBM is funding most of the work, my guess is the main use-case here is IBM's POWER-based HPC clusters that have PowerPC CPUs augmented by a bunch of GPU coprocessors for Cuda/OpenCL offloading. IBM is trying to position POWER clusters as competing with x86-based clusters for certain kinds of work (especially scientific computing), and to match x86-based clusters decked out with GPUs they probably need to have GPU options for their POWER-based clusters as well.
The idea, as I read it (have not had occasion to encounter it myself) is that things are a lot easier if your CPU and GPU have the same endianness, or else you have to byte-swap whenever transferring data to/from the GPU (and there are even more complications if you have unified memory spaces). Since most (all?) commercially available GPUs are little-endian, if you want PowerPC CPUs along with GPUs for auxiliary processing, and want the endianness matched, the little-endian mode of PowerPC becomes important.