Linux doesn't ever run the cpu in the RMO memory model any more. All
sparc64 chips run only in TSO now.
All of the Niagara chips implement an even stricter than TSO memory
model, and the membars we used to have all over the kernel to handle
that properly were just wasted I-cache space. So
Let's clarify something, did you run your testcase that triggered this
bug on a v8 or a v9 machine?
Sun UltraSPARC, so V9 of course. The point is that Solaris is TSO (TSO as
defined for the V9 architecture, i.e. backward compatible with V8) so you have
a V8-compatible TSO implementation, in
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 28 Jun 2011 10:11:03 +0200
The V8 architecture manual is quite clear about it: TSO allows stores to be
reordered after subsequent loads (it's the only difference in TSO with Strong
Consistency) so you need to do something to have a full
Fair enough, you can add this code if you want.
Thanks. Note that this is marginal for Solaris as GCC defaults to -mcpu=v9 on
Solaris but, in all other cases, it defaults to -mcpu=v8. I can reproduce the
problem on the SPARC/Linux machine 'grobluk' of the CompileFarm:
cpu : TI
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 28 Jun 2011 23:27:43 +0200
With the pristine compiler, the test passes with -mcpu=v9 but fails otherwise.
It passes with the patched compiler. However, I suspect that we would still
have problems with newer UltraSparc CPUs supporting full
From: Eric Botcazou ebotca...@adacore.com
Date: Mon, 27 Jun 2011 18:11:10 +0200
* config/sparc/sync.md (*stbar): Delete.
(*membar_v8): New insn to implement UNSPEC_MEMBAR in SPARC-V8.
Code which cares about memory ordering etc. really has to know
the kind of cpu it is running on.
On Jun 27, 2011, at 19:00, David Miller da...@davemloft.net wrote:
V8 can only reorder stores, that's why it only has a 'stbar'
instruction. I'm not so sure I agree with trying to paper over the
fact that someone has compiled code for v8 that's going to run on a v9
cpu.
That's not the
From: Geert Bosch bo...@adacore.com
Date: Mon, 27 Jun 2011 19:36:06 -0400
On Jun 27, 2011, at 19:00, David Miller da...@davemloft.net wrote:
V8 can only reorder stores, that's why it only has a 'stbar'
instruction. I'm not so sure I agree with trying to paper over the
fact that someone has
On Jun 27, 2011, at 19:53, David Miller wrote:
I'm trying to find the part of the v8 manual that says there is
a situation where we should use stbar and a ldstub to implement
proper memory barriers. In particular I'm looking in Appendix J,
Programming with the memory models. Where is the
From: Geert Bosch bo...@adacore.com
Date: Mon, 27 Jun 2011 22:21:47 -0400
On Jun 27, 2011, at 19:53, David Miller wrote:
Adding a ldstub here is going to be really expensive, on UltraSparc
that can be 36+ cycles even on a cache hit.
Yes, synchronization in multi-CPU systems is expensive.
On Jun 27, 2011, at 22:45, David Miller wrote:
From: Geert Bosch bo...@adacore.com
Date: Mon, 27 Jun 2011 22:21:47 -0400
On Jun 27, 2011, at 19:53, David Miller wrote:
Adding a ldstub here is going to be really expensive, on UltraSparc
that can be 36+ cycles even on a cache hit.
Yes,
From: Geert Bosch bo...@adacore.com
Date: Mon, 27 Jun 2011 23:17:18 -0400
\You then go on to speak about LEON, does LEON implement PSO?
No, I'm not talking about PSO anywhere or SPARCv9 anywhere.
Just plain old SPARCv8, using the TSO model. This requires a
load-store instruction to guarantee
12 matches
Mail list logo
