[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Fwd: [lemote] Re: Are -mfix-loongson2f-nop and -mfix-loongson2f-jump needed for userland programs?]



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.

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

Cheers,
-- 
Daniel JB Clark | Free Software Activist | http://pobox.com/~dclark


Reply to: