On 2015-06-09 12:02, David Miller wrote: > From: James Y Knight <jyknight@xxxxxxxxxx> > Date: Tue, 9 Jun 2015 08:13:58 -0400 > > > Um, but my test isn't testing what is being stored to memory at > > all. It is storing to memory and **never loading from the memory > > after**. Why would writing FROM fp registers TO memory corrupt the > > *registers* due to a missing memory barrier? > > The memory barrier is necessary for two reasons, only one of them is > to handle the asynchronousness of the memory operations. > > The other reason is that there are strict rules for accessing the FPU > register file around block loads and stores. > > Therefore if you don't do the proper memory barriers you can get > corrupted FPU register as well as memory contents. > > And complicating things even more, what you can get away with is > different on every single cpu variant. That's why I really wish So it means the userland code doesn't run the same on the various CPU. How are we supposed to do with static binaries? > debian didn't disable multiarch as that makes the code use the > UltraSPARC-I/II/III memcpy, which might not be %100 kosher on > Niagara-T1 and later. The UltraSPARC-I/II/III memcpy code might have issues, but it clearly works a lot better than the Niagara-T1 code on a Niagara-T1 machine. Disabling multiarch support improves a lot the stability on these machines. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@xxxxxxxxxxx http://www.aurel32.net -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
