small fix for mips
Jamal Hadi Salim
jhs at mojatatu.com
Wed Jul 3 13:44:16 CEST 2013
BTW, I should point out I had no problem compiling and running
the original code for multicore MIPS (64 bit Octeon with 8 CPUs).
I havent compiled this changed version for that processor target.
I suspect there will be no problem.
On 13-07-03 07:35 AM, Jamal Hadi Salim wrote:
> 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:
> 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")
More information about the libev