[Top] [All Lists]

Re: PATCH: Fix ll/sc for mips (take 3)

To: Dominic Sweetman <>
Subject: Re: PATCH: Fix ll/sc for mips (take 3)
From: Jay Carlson <>
Date: Tue, 5 Feb 2002 01:16:46 -0500
Cc: Jay Carlson <>, Hiroyuki Machida <>,,
In-reply-to: <>

On Monday, February 4, 2002, at 04:32 AM, Dominic Sweetman wrote:

Hiroyuki Machida ( writes:

I think we can assume CPU has branch-likely insns, if CPU has MIPS
ISA 2 or greater ISA..

"MIPS II" is officially the instruction set introduced for the long
lost R6000 CPU.

But "MIPS II" is now used to mean "the 32-bit subset of MIPS III"
(which is extremely close to the same thing, but I'm never quite sure
about the last details of the R6000 - Kevin would remember better,

OK: branch-likely is definitely part of MIPS II and MIPS32.  There are
still MIPS CPUs in regular use which are based on MIPS I and don't
provide them.  Generally the advantages of MIPS II are slight, so if
you want to build a kernel which will not require instruction-set
variants, it's no big deal to restrict it to MIPS I.

There's load interlocks, which you can depend on starting with MIPS II. They're also present on the TX39 and VR41xx.

For non-PIC code, I see around a 5-7% reduction in userland code size by compiling with -Wa,-mips2, which afaict just eliminates the generation of nops after loads. The compiler is still generating code anticipating the delays, which is good.

For PIC code, I remember the benefits being in the same range. And you're fighting gas, which will generate load-delay nops in the middle of la/lw/sw macro expansions in PIC mode regardless of what mips architecture you're building for. I made some patches against an older binutils to eliminate those nops for mips2 and up, and got ANOTHER 5-7%, of course depending on actual instruction mix.

Given that I tossed out the SVR4 ABI in search of code density in snow, I'm probably a little abnormal in these concerns. But other people on small platforms may care.


<Prev in Thread] Current Thread [Next in Thread>