small fix for mips
schmorp at schmorp.de
Wed Jul 3 18:20:19 CEST 2013
On Wed, Jul 03, 2013 at 07:35:48AM -0400, Jamal Hadi Salim <jhs at mojatatu.com> wrote:
> >For openwrt targets that don't do smp (almost all?),
> There may be an odd one that does - nothing Ive come across yet.
Surely none of them use mips1.
> 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
> 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.
I can't see how this would be possible - if I tell the assembler that my
target supports sync and then tell it to assemble a sync insn, it has no
way of making it a nop.
It might be possible that a mips1 cpu simply ignores unknown instructions
though, or this unknown instruction.
> >(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.
Exactly, anything current should run mips32, or at least mips2.
My point is, your change requires mips2 already, so compiling for a
mips1 target architecture is already wrong (especially as mips1 is a lot
less efficient due to the many extra nops required to fill various delay
The fix might STILL be required even when compiling for mips2 or newer,
but I somehow doubt it.
And yes, if somebody who actually knows more about mips architectures can
shed some light on this, this would be greatly appreciated :)
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp at schmorp.de
More information about the libev