small fix for mips

Jamal Hadi Salim jhs at mojatatu.com
Wed Jul 3 13:35:48 CEST 2013


On 13-07-02 11:57 PM, Marc Lehmann wrote:

> For openwrt targets that don't do smp (almost all?),

There may be an odd one that does - nothing Ive come across yet.

> a simpler and more
> performant solution might be to compile with -DECB_NO_SMP=1, which
> completely disables fences, which would be unneeded in this case.
>

Indeed. I will give this a try sometime today - it is a better option.

But you may still have problems with SMP MIPS. While grokking around
trying to fix this i came across points of views such as:
http://www.open-mpi.org/hg/hgwebdir.cgi/ompi-svn-mirror/file/515213f88f5e/opal/include/opal/sys/mips/atomic.h

Hence my comment this might be Linuxish - or as usual in the open
source world, one person started with that approach and everyone else 
cutnpasted ;-> (the FIX ME comment on openmpi code seems to be floating
around as well; doesnt inspire a lot of faith in the correctness).

> When compiling for mips1, wouldn't sync cause problems because the
> architecture doesn't support it?
>

I think in that case it becomes a noop with newer assemblers.

> When the target architecture is indeed not mips1, but mips2, wouldn't it
> be better to tell the compiler about it?
>
> (are there actually any mips1 chips still in use?)

The mips1 instruction set is still in use - doubt if there is
architecture out there that is purely running mips1 and nothing else.
CCing Ralf (the MIPS guru). Ralf, discussion context is memory barriers, 
  openwrt (single core 32 bit mips in my  case) requires for libev to 
compile this change:

--------
-    __asm__ __volatile__ ("sync"     : : : "memory")
+    __asm__ __volatile__ (".set mips2; sync; .set mips0" ::: "memory")
---

cheers,
jamal




More information about the libev mailing list