On Sun, 08 Feb 2015 17:55:10 +0100 Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 07.02.2015 19:49, Stefan Tauner wrote:
Was implemented by SPARC newbies, does (cross-)compile but is not run-tested.
Signed-off-by: Stefan Tauner stefan.tauner@alumni.tuwien.ac.at
Thanks!
Quoting wikipedia:
The endianness of the 32-bit SPARC V8 architecture is purely big-endian. The 64-bit SPARC V9 architecture uses big-endian instructions, but can access data in either big-endian or little-endian byte order, chosen either at the application instruction (load/store) level or at the memory page level (via an MMU setting). The latter is often used for accessing data from inherently little-endian devices, such as those on PCI buses.
If that is true, we are totally screwed. How can we even begin to influence the instructions emitted by the compiler? And if the compiler emits bigendian instructions by default, can that be overridden via MMU setting? If yes, does Linux use the endianness manipulation via MMU for PCI devices, in which case we'd have to treat the architecture as littleendian from a flashrom POV?
This is a nightmare.
Only if you make it one. :) Maybe this allows you to sleep better: https://gcc.gnu.org/ml/gcc-patches/2011-10/msg02240.html
I am not sure if that "MMU settings" in wikipedia is referring to the address space identifiers (ASIs), but it definitely screams [citation needed]. In general the whole thing looks like a rather exotic if not esoteric feature added to make porting Windows easier... in any case I am very confident that it will not be encountered on real machines/OSes.
So... the only question is if you agree and we commit this before tagging 0.9.8-rc1 or not. I don't care too much about SPARC support, but I *do* care about getting the release out. Please respond in a timely manner.