lkml.org 
[lkml]   [2015]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] MIPS: R6: Use lightweight SYNC instruction in smp_* memory barriers
On Tue, Jun 02, 2015 at 11:08:35AM +0100, Paul Burton wrote:
> Hi Leonid,
>

<snip>

> > +
> > + If that instructions are not implemented in processor then it is
> > + converted to generic "SYNC 0".
>
> I think this would read better as something like:
>
> If a processor does not implement the lightweight sync operations then
> the architecture requires that they interpret the corresponding sync
> instructions as the typical heavyweight "sync 0". Therefore this
> should be safe to enable on all CPUs implementing release 2 or
> later of the MIPS architecture.
>

Is it really the case for release 2?

I'm asking because recently I needed to do something similar and I couldn't
find this garantee in the revision 2.00 of the manual.
May it's just poorly formulated but here is what I find in it:
- "The stype values 1-31 are reserved for future extensions to the architecture."
(ok)
- "A value of zero will always be defined such that it performs all defined
synchronization operations." (ok)
- "Non-zero values may be defined to remove some synchronization operations."
(ok, certainly if we understand the word "weaker" instead of "remove")
- "As such, software should never use a non-zero value of the stype field, as
this may inadvertently cause future failures if non-zero values remove
synchronization operations." (Mmmm, ok but ...)
Nowhere is there something close to what is found in the revision 5.0 or later:
"If an implementation does not use one of these non-zero values to define a
different synchronization behavior, then that non-zero value of stype must
act the same as stype zero completion barrier."

The wording may have changed since revision 2.8 but I don't have access to the
corresponding manual.


Luc Van Oostenryck


\
 
 \ /
  Last update: 2015-06-02 15:01    [W:0.166 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site