This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: MIPS clones without lwl/lwr/swl/swr
- From: Thiemo Seufer <ths at networkno dot de>
- To: Richard Sandiford <rsandifo at redhat dot com>
- Cc: Marek Michalkiewicz <marekm at amelek dot gda dot pl>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 14 May 2005 12:46:10 +0200
- Subject: Re: RFC: MIPS clones without lwl/lwr/swl/swr
- References: <20050513145612.GA17580@amelek.gda.pl> <873bsqp874.fsf@firetop.home>
Richard Sandiford wrote:
> Marek Michalkiewicz <marekm@amelek.gda.pl> writes:
> > The patch below (for mainline) is an attempt to support MIPS clones
> > which don't have the patented lwl/lwr/swl/swr instructions. This
> > would be useful mainly for the Realtek RTL8181 "Wireless LAN Access
> > Point / Gateway Controller", based on the Lexra core. Linux/uClibc
> > port for the RTL8181 is available at http://rtl8181.sourceforge.net/ .
> >
> > This is not tested (other than it compiles), so not meant for
> > inclusion in the official GCC source just yet - but I kindly ask
> > you (especially MIPS hackers, because I'm not yet very familiar
> > with this architecture) to review it and tell me if it looks good.
>
> Looks good to me.
>
> The MIPS port usually guards this sort of instruction selection with an
> ISA_HAS_* macro (ISA_HAS_COND_TRAP, ISA_HAS_CLZ_CLO, etc.). One thing
> I'd like to see is a new ISA_HAS_* macro to say whether lwl/lwr,
> etc. are available.
I don't think those should be handled as a separate ISA, for several
reasons:
- A separate ISA definition for four missing insns is very heavyweight.
- There might be CPUs which conform to different ISAs except for those
instructions.
- The patents are IIRC running out soon-ish, which makes it less likely
for new CPUs to come without lwl/lwr/...
> The macro would be false if your new option is
> passed and would also be false for TARGET_MIPS16.
This sounds ...wrong. MIPS16 is not an ISA, and CPUs with MIPS16 ASE
typically have lwl/lwr/... I see that some ISA_HAS_* macros test
for TARGET_MIPS16, AFAICS this will bite us if we ever start to support
mixed mode compilation (with the mode determined by profiling data).
A GENERATE_PATENTED macro seems to be a better choice.
> If at some point
> in the future, -march is extended to support a processor without the
> patented instructions, the macro would be false when generating code
> for that processor.
>
> > Suggestions for a better name for this option are also welcome.
>
> I've no strong opinions about that, but I don't see any need to
> shorten "patent-free" to "patfree".
-m{,no-}patent-free is ok IMHO. For convenience there should also be a
-march=rtl8181 switch which implies the patent free mode.
Thiemo