small fix for mips

Ralf Baechle ralf at linux-mips.org
Thu Jul 4 12:58:47 CEST 2013


On Wed, Jul 03, 2013 at 07:35:48AM -0400, Jamal Hadi Salim wrote:

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

No - see below.

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

No - that'd be a serious bug in the assembler.

> >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")
> ---

A bunch of people are still messing around with embedded systems based on
the IDT R3081 even though that part was already EOL'ed a few years ago.
Another R3000-compatible part that is still available new is the Moongoose V,
a radiation hardened version.  As usual for this class of parts it's way,
way behind the state of the art here on earth.  Also two parts will set
you back by just $42,225 ...

The Linux solution to deal with the unavailability of SYNC, LL and SC
instruction on R3000-class CPUs is to emulate them in the kernel.

In other words, the minimum instruction set application code can expect
on Linux/MIPS is MIPS I + SYNC + LL + SC.  The reason for this in-kernel
emulation is that it allows binary compatibility with later architecture
revisions and reasonable performance.  As such the .set mips2 version
above is the recommended approach.

An alternative that'd be portable would be the sysmips(MIPS_ATOMIC_SET, ...)
syscall.  It'd perform better on MIPS I processors but punish anything
more modern so its use is discouraged unless optimizing code for MIPS I.
And who would do that these days?

  Ralf



More information about the libev mailing list