Re: [Fwd: [lemote] Re: Are -mfix-loongson2f-nop and -mfix-loongson2f-jump needed for userland programs?]
Hi,
On Thursday 04 February 2010 04:43:44 Daniel Clark wrote:
> On Wed, Feb 3, 2010 at 10:15 PM, fxzhang <fxzhang@ict.ac.cn> wrote:
> > FYI
> > ---
> >
> > On Sat, 2010-01-23 at 13:39 -0500, Daniel Clark wrote:
> >> Does anyone know canonically if the system can have instability
> >> because *any* executable program is compiled without the loongson2f
> >> as/binutils fixes?
> >>
> >> The site http://dev.lemote.com/code/firefox-3.7-loongson-jit says:
> >>
> >> "Recommend building with Lemote's tool-chain
> >> http://dev.lemote.com/files/binary/toolchain/gcc4ls2f.tar to avoid a
> >> potential bug http://sourceware.org/ml/binutils/2009-11/msg00387.html.";
> >>
> >> I was under the impression that only the kernel, linux had to be
> >> compiled with the loongson2f as/binutils fixes to avoid system lockups
> >> due to silicon-level loongson2f bugs.
> >
> > As I have said in
> > http://sourceware.org/ml/binutils/2009-11/msg00387.html, only
> > -mfix-loongson2f-nop is needed for user-space applications.
> >
> >> If this is wrong then I feel gNewSense (a Debian-based GNU/Linux
> >> distribution) might as well spend the time to make a n32 ABI /
> >> loongson2f / loongson2f as bug fixes variant of gNewSense now, rather
> >> then waiting on the Debian work in that area [1].
> >
> > Yes, It's better to compile all of the applications with
> > -mfix-loongson2f-nop.
> >
> > The n32 porting is really a very good message to us, which may bring us
> > with better performance about +30%(?).
> >
> > Seems the best options combination is: -O3 -march=loongson2f -mabi=n32.
> >
> >> Also, I have been told recently produced loongson2f chips have fixed
> >> these bugs, so not everyone may see them. Does anyone know how to tell
> >> if one has a version of the loongson2f chip with the bug that requires
> >> the binutils patches?
> >
> > I'm not sure which exact revision of loongson2f have fixed these bugs,
> > but we may distinguish them via the revision number in the register of
> > processor(Processor Revision Identifier (PRID) Register).
> >
> > And since the workaround method(repaces the nop instruction by another
> > dummy instruction: "or at,at,zero") used by -mfix-loongson2f-nop have no
> > big side effect(some testing is needed to verify it), so, it's better to
> > enable it for all of the loongson2f processors.
> >
> > Regards,
> > Wu Zhangjin
>
> Was going to reply to other thread, but probably more appropriate here
> - IMHO the future of non-embedded general-purpose MIPSel boxes seems
> to be with the loongson series of processors; there are lots of people
> in China, lots of units have already shipped, and the future roadmap
> looks pretty sweet (loongson 3 due sometime this year I think will
> have on-silicon support for qemu x86 emulation, claim is ~70% speed of
> x86 in emulation, as well as in general being much faster than current
> generation; also there was already a top500 loongson2f box.)
>
> As far as I could find there aren't any general-purpose computers
> available from alive vendors with Cavium MIPS chips.
This is right, a couple of company claim they manufacture mobos with Octeon
chips on it, but I could not find any distributor for it yet.
>
> XBurst MIPS is also used by some interesting small devices, notably
> the Ben Nanonote, but I think that that would probably be better
> served by emdebian as resources are pretty low (they are going to ship
> with OpenWRT).
The Ben Nanonote probably needs to reach a stable and popular state before
someone starts some serious Debian work for it, but yes this is one potential
popular MIPSel device too.
--
Florian
Reply to: